Unsafe是位于sun.misc包下的一个类，主要提供一些用于执行低级别、不安全操作的方法，如直接访问系统内存资源、自主管理内存资源等，这些方法在提升Java运行效率、增强Java语言底层资源操作能力方面起到了很大的作用。但由于Unsafe类使Java语言拥有了类似C语言指针一样操作内存空间的能力，这无疑也增加了程序发生相关指针问题的风险。在程序中过度、不正确使用Unsafe类会使得程序出错的概率变大，使得Java这种安全的语言变得不再“安全”，因此对Unsafe的使用一定要慎重。

我们可以用unsafe 实现一个自己的AtomicInteger

package com.conrrentcy.atomic;

import java.lang.reflect.Field;

import sun.misc.Unsafe;

public class MyAtomicInteger {
    private volatile int value;
    private static final Unsafe unsafe ;
    private final static  long offset;
    static {
        try{
        Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
        theUnsafe.setAccessible(true);
        unsafe= (Unsafe) theUnsafe.get(null);
        
        offset = unsafe.objectFieldOffset(MyAtomicInteger.class.getDeclaredField("value"));
        }catch(Exception e){
            throw new RuntimeException(e);
        }
    }
    
    public int getValue(){
        return value;
    }

    public void decrease(int amount){
        
        while(true){
            
            int pre = this.value;
            
            int next = pre -amount;
            
            if(unsafe.compareAndSwapInt(this, offset, pre, next)){
                break;
            }
        }
        
    }
    


}

通常我们最好也不要使用Unsafe类，除非有明确的目的，并且也要对它有深入的了解才行。要想使用Unsafe类需要用一些比较tricky的办法。Unsafe类使用了单例模式，需要通过一个静态方法getUnsafe()来获取。但Unsafe类做了限制，如果是普通的调用的话，它会抛出一个SecurityException异常；只有由主类加载器加载的类才能调用这个方法。其源码如下：

public static Unsafe getUnsafe() {
    Class var0 = Reflection.getCallerClass();
    if(!VM.isSystemDomainLoader(var0.getClassLoader())) {
        throw new SecurityException("Unsafe");
    } else {
        return theUnsafe;
    }
}

那如若想使用这个类，该如何获取其实例？有如下两个可行方案。

• 从getUnsafe方法的使用限制条件出发，通过Java命令行命令-Xbootclasspath/a把调用Unsafe相关方法的类A所在jar包路径追加到默认的bootstrap路径中，使得A被引导类加载器加载，从而通过Unsafe.getUnsafe方法安全的获取Unsafe实例。
  java -Xbootclasspath/a: ${path} // 其中path为调用Unsafe相关方法的类所在jar包路径
• 通过反射获取单例对象theUnsafe。

private static Unsafe reflectGetUnsafe() {
    try {
      Field field = Unsafe.class.getDeclaredField("theUnsafe");
      field.setAccessible(true);
      return (Unsafe) field.get(null);
    } catch (Exception e) {
      log.error(e.getMessage(), e);
      return null;
    }

获取到Unsafe实例之后，我们就可以为所欲为了。Unsafe类提供了以下这些功能：

内存管理。包括分配内存、释放内存等。

这部分主要包含堆外内存的分配、拷贝、释放、给定地址值操作等方法

该部分包括了allocateMemory（分配内存）、reallocateMemory（重新分配内存）、copyMemory（拷贝内存）、freeMemory（释放内存 ）、getAddress（获取内存地址）、addressSize、pageSize、getInt（获取内存地址指向的整数）、getIntVolatile（获取内存地址指向的整数，并支持volatile语义）、putInt（将整数写入指定内存地址）、putIntVolatile（将整数写入指定内存地址，并支持volatile语义）、putOrderedInt（将整数写入指定内存地址、有序或者有延迟的方法）等方法。getXXX和putXXX包含了各种基本类型的操作。

利用copyMemory方法，我们可以实现一个通用的对象拷贝方法，无需再对每一个对象都实现clone方法，当然这通用的方法只能做到对象浅拷贝。

通常，我们在Java中创建的对象都处于堆内内存（heap）中，堆内内存是由JVM所管控的Java进程内存，并且它们遵循JVM的内存管理机制，JVM会采用垃圾回收机制统一管理堆内存。与之相对的是堆外内存，存在于JVM管控之外的内存区域，Java中对堆外内存的操作，依赖于Unsafe提供的操作堆外内存的native方法。

使用堆外内存的原因

对垃圾回收停顿的改善。由于堆外内存是直接受操作系统管理而不是JVM，所以当我们使用堆外内存时，即可保持较小的堆内内存规模，从而在GC时减少回收停顿对于应用的影响。
提升程序I/O操作的性能。通常在I/O通信过程中，会存在堆内内存到堆外内存的数据拷贝操作，对于需要频繁进行内存间数据拷贝且生命周期较短的暂存数据，都建议存储到堆外内存。
典型应用

DirectByteBuffer是Java用于实现堆外内存的一个重要类，通常用在通信过程中做缓冲池，如在Netty、MINA等NIO框架中应用广泛。DirectByteBuffer对于堆外内存的创建、使用、销毁等逻辑均由Unsafe提供的堆外内存API来实现。

下图为DirectByteBuffer构造函数，创建DirectByteBuffer的时候，通过Unsafe.allocateMemory分配内存、Unsafe.setMemory进行内存初始化，而后构建Cleaner对象用于跟踪DirectByteBuffer对象的垃圾回收，以实现当DirectByteBuffer被垃圾回收时，分配的堆外内存一起被释放。

    // Primary constructor
    //
    DirectByteBuffer(int cap) {                   // package-private

        super(-1, 0, cap, cap);
        boolean pa = VM.isDirectMemoryPageAligned();
        int ps = Bits.pageSize();
        long size = Math.max(1L, (long)cap + (pa ? ps : 0));
        Bits.reserveMemory(size, cap);

        long base = 0;
        try {
            base = UNSAFE.allocateMemory(size);
        } catch (OutOfMemoryError x) {
            Bits.unreserveMemory(size, cap);
            throw x;
        }
        UNSAFE.setMemory(base, size, (byte) 0);
        if (pa && (base % ps != 0)) {
            // Round up to page boundary
            address = base + ps - (base & (ps - 1));
        } else {
            address = base;
        }
        cleaner = Cleaner.create(this, new Deallocator(base, size, cap));
        att = null;

    }

那么如何通过构建垃圾回收追踪对象Cleaner实现堆外内存释放呢？

Cleaner继承自Java四大引用类型之一的虚引用PhantomReference（众所周知，无法通过虚引用获取与之关联的对象实例，且当对象仅被虚引用引用时，在任何发生GC的时候，其均可被回收），通常PhantomReference与引用队列ReferenceQueue结合使用，可以实现虚引用关联对象被垃圾回收时能够进行系统通知、资源清理等功能。如下图所示，当某个被Cleaner引用的对象将被回收时，JVM垃圾收集器会将此对象的引用放入到对象引用中的pending链表中，等待Reference-Handler进行相关处理。其中，Reference-Handler为一个拥有最高优先级的守护线程，会循环不断的处理pending链表中的对象引用，执行Cleaner的clean方法进行相关清理工作。

image.png

所以当DirectByteBuffer仅被Cleaner引用（即为虚引用）时，其可以在任意GC时段被回收。当DirectByteBuffer实例对象被回收时，在Reference-Handler线程操作中，会调用Cleaner的clean方法根据创建Cleaner时传入的Deallocator来进行堆外内存的释放

     */
    static boolean tryHandlePending(boolean waitForNotify) {
        Reference<Object> r;
        Cleaner c;
        try {
            synchronized (lock) {
                if (pending != null) {
                    r = pending;
                    // 'instanceof' might throw OutOfMemoryError sometimes
                    // so do this before un-linking 'r' from the 'pending' chain...
                    c = r instanceof Cleaner ? (Cleaner) r : null;
                    // unlink 'r' from 'pending' chain
                    pending = r.discovered;
                    r.discovered = null;
                } else {
                    // The waiting on the lock may cause an OutOfMemoryError
                    // because it may try to allocate exception objects.
                    if (waitForNotify) {
                        lock.wait();
                    }
                    // retry if waited
                    return waitForNotify;
                }
            }
        } catch (OutOfMemoryError x) {
            // Give other threads CPU time so they hopefully drop some live references
            // and GC reclaims some space.
            // Also prevent CPU intensive spinning in case 'r instanceof Cleaner' above
            // persistently throws OOME for some time...
            Thread.yield();
            // retry
            return true;
        } catch (InterruptedException x) {
            // retry
            return true;
        }

        // Fast path for cleaners
        if (c != null) {
            c.clean();
            return true;
        }

        ReferenceQueue<? super Object> q = r.queue;
        if (q != ReferenceQueue.NULL) q.enqueue(r);
        return true;
    }

非常规的对象实例化。

allocateInstance()方法提供了另一种创建实例的途径。通常我们可以用new或者反射来实例化对象，使用allocateInstance()方法可以直接生成对象实例，且无需调用构造方法和其它初始化方法。

这在对象反序列化的时候会很有用，能够重建和设置final字段，而不需要调用构造方法。

典型应用

常规对象实例化方式：我们通常所用到的创建对象的方式，从本质上来讲，都是通过new机制来实现对象的创建。但是，new机制有个特点就是当类只提供有参的构造函数且无显示声明无参构造函数时，则必须使用有参构造函数进行对象构造，而使用有参构造函数时，必须传递相应个数的参数才能完成对象实例化。
非常规的实例化方式：而Unsafe中提供allocateInstance方法，仅通过Class对象就可以创建此类的实例对象，而且不需要调用其构造函数、初始化代码、JVM安全检查等。它抑制修饰符检测，也就是即使构造器是private修饰的也能通过此方法实例化，只需提类对象即可创建相应的对象。由于这种特性，allocateInstance在java.lang.invoke、Objenesis（提供绕过类构造器的对象生成方式）、Gson（反序列化时用到）中都有相应的应用。
如下图所示，在Gson反序列化时，如果类有默认构造函数，则通过反射调用默认构造函数创建实例，否则通过UnsafeAllocator来实现对象实例的构造，UnsafeAllocator通过调用Unsafe的allocateInstance实现对象的实例化，保证在目标类无默认构造函数时，反序列化不够影响。

com.google.gson.internal.ConstructorConstructor

public <T> ObjectConstructor<T> get(TypeToken<T> typeToken) {
    final Type type = typeToken.getType();
    final Class<? super T> rawType = typeToken.getRawType();

    // first try an instance creator

    @SuppressWarnings("unchecked") // types must agree
    final InstanceCreator<T> typeCreator = (InstanceCreator<T>) instanceCreators.get(type);
    if (typeCreator != null) {
      return new ObjectConstructor<T>() {
        @Override public T construct() {
          return typeCreator.createInstance(type);
        }
      };
    }

    // Next try raw type match for instance creators
    @SuppressWarnings("unchecked") // types must agree
    final InstanceCreator<T> rawTypeCreator =
        (InstanceCreator<T>) instanceCreators.get(rawType);
    if (rawTypeCreator != null) {
      return new ObjectConstructor<T>() {
        @Override public T construct() {
          return rawTypeCreator.createInstance(type);
        }
      };
    }

    ObjectConstructor<T> defaultConstructor = newDefaultConstructor(rawType);
    if (defaultConstructor != null) {
      return defaultConstructor;
    }

    ObjectConstructor<T> defaultImplementation = newDefaultImplementationConstructor(type, rawType);
    if (defaultImplementation != null) {
      return defaultImplementation;
    }

    // finally try unsafe
    return newUnsafeAllocator(type, rawType);
  }

UnsafeAllocator

public abstract class UnsafeAllocator {
  public abstract <T> T newInstance(Class<T> c) throws Exception;

  public static UnsafeAllocator create() {
    // try JVM
    // public class Unsafe {
    //   public Object allocateInstance(Class<?> type);
    // }
    try {
      Class<?> unsafeClass = Class.forName("sun.misc.Unsafe");
      Field f = unsafeClass.getDeclaredField("theUnsafe");
      f.setAccessible(true);
      final Object unsafe = f.get(null);
      final Method allocateInstance = unsafeClass.getMethod("allocateInstance", Class.class);
      return new UnsafeAllocator() {
        @Override
        @SuppressWarnings("unchecked")
        public <T> T newInstance(Class<T> c) throws Exception {
          assertInstantiable(c);
          return (T) allocateInstance.invoke(unsafe, c);
        }
      };
    } catch (Exception ignored) {
    }

操作类、对象、变量。

这部分包括了staticFieldOffset（静态域偏移）、defineClass（定义类）、defineAnonymousClass（定义匿名类）、ensureClassInitialized（确保类初始化）、objectFieldOffset（对象域偏移）等方法。

通过这些方法我们可以获取对象的指针，通过对指针进行偏移，我们不仅可以直接修改指针指向的数据（即使它们是私有的），甚至可以找到JVM已经认定为垃圾、可以进行回收的对象。

此部分主要提供Class和它的静态字段的操作相关方法，包含静态字段内存定位、定义类、定义匿名类、检验&确保初始化等。

//获取给定静态字段的内存地址偏移量，这个值对于给定的字段是唯一且固定不变的
public native long staticFieldOffset(Field f);
//获取一个静态类中给定字段的对象指针
public native Object staticFieldBase(Field f);
//判断是否需要初始化一个类，通常需要使用在获取一个类的静态属性的时候(因为一个类如果没初始化，它的静态属性也不会初始化)。 此方法当且仅当ensureClassInitialized方法不生效的时候才返回false。
public native boolean shouldBeInitialized(Class<?> c);
//检测给定的类是否已经初始化。通常需要使用在获取一个类的静态属性的时候(因为一个类如果没初始化，它的静态属性也不会初始化)。
public native void ensureClassInitialized(Class<?> c);
//定义一个类，此方法会跳过JVM的所有安全检查，默认情况下，ClassLoader(类加载器)和ProtectionDomain(保护域)实例来源于调用者
public native Class<?> defineClass(String name, byte[] b, int off, int len, ClassLoader loader, ProtectionDomain protectionDomain);
//定义一个匿名类
public native Class<?> defineAnonymousClass(Class<?> hostClass, byte[] data, Object[] cpPatches);

典型应用

从Java 8开始，JDK使用invokedynamic及VM Anonymous Class结合来实现Java语言层面上的Lambda表达式。
在Lambda表达式实现中，通过invokedynamic指令调用引导方法生成调用点，在此过程中，会通过ASM动态生成字节码，而后利用Unsafe的defineAnonymousClass方法定义实现相应的函数式接口的匿名类，然后再实例化此匿名类，并返回与此匿名类中函数式方法的方法句柄关联的调用点；而后可以通过此调用点实现调用相应Lambda表达式定义逻辑的功能。下面以如下图所示的Test类来举例说明。
invokedynamic： invokedynamic是Java 7为了实现在JVM上运行动态语言而引入的一条新的虚拟机指令，它可以实现在运行期动态解析出调用点限定符所引用的方法，然后再执行该方法，invokedynamic指令的分派逻辑是由用户设定的引导方法决定。
VM Anonymous Class：可以看做是一种模板机制，针对于程序动态生成很多结构相同、仅若干常量不同的类时，可以先创建包含常量占位符的模板类，而后通过Unsafe.defineAnonymousClass方法定义具体类时填充模板的占位符生成具体的匿名类。生成的匿名类不显式挂在任何ClassLoader下面，只要当该类没有存在的实例对象、且没有强引用来引用该类的Class对象时，该类就会被GC回收。故而VM Anonymous Class相比于Java语言层面的匿名内部类无需通过ClassClassLoader进行类加载且更易回收。

在Lambda表达式实现中，通过invokedynamic指令调用引导方法生成调用点，在此过程中，会通过ASM动态生成字节码，而后利用Unsafe的defineAnonymousClass方法定义实现相应的函数式接口的匿名类，然后再实例化此匿名类，并返回与此匿名类中函数式方法的方法句柄关联的调用点；而后可以通过此调用点实现调用相应Lambda表达式定义逻辑的功能。

public class TEST {

    public static void main(String[] args) {
        Consumer consumer =s ->System.out.println(s);
        consumer.accept("lamda");

    }

}

Test类编译后的class文件反编译后的结果如下图一所示，我们可以从中看到main方法的指令实现、invokedynamic指令调用的引导方法BootstrapMethods、及静态方法lambda0（实现了Lambda表达式中字符串打印逻辑）等。在引导方法执行过程中InnerClassLambdaMetafactory::buildCallSite->spinInnerClass，会通过Unsafe.defineAnonymousClass生成如下图二所示的实现Consumer接口的匿名类。其中，accept方法通过调用Test类中的静态方法lambda0来实现Lambda表达式中定义的逻辑。而后执行语句consumer.accept（"lambda"）其实就是调用下图二所示的匿名类的accept方法。

// Compiled from TEST.java (version 1.8 : 52.0, super bit)
public class TEST {
  
  // Method descriptor #10 ()V
  // Stack: 1, Locals: 1
  public TEST();
    0  aload_0 [this]
    1  invokespecial java.lang.Object() [1]
    4  return
      Line numbers:
        [pc: 0, line: 5]
      Local variable table:
        [pc: 0, pc: 5] local: this index: 0 type: TEST
  
  // Method descriptor #17 ([Ljava/lang/String;)V
  // Stack: 2, Locals: 2
  public static void main(java.lang.String[] args);
     0  invokedynamic 0 accept() : java.util.function.Consumer [2]
     5  astore_1 [consumer]
     6  aload_1 [consumer]
     7  ldc <String "lamda"> [3]
     9  invokeinterface java.util.function.Consumer.accept(java.lang.Object) : void [4] [nargs: 2]
    14  return
      Line numbers:
        [pc: 0, line: 8]
        [pc: 6, line: 9]
        [pc: 14, line: 11]
      Local variable table:
        [pc: 0, pc: 15] local: args index: 0 type: java.lang.String[]
        [pc: 6, pc: 15] local: consumer index: 1 type: java.util.function.Consumer
  
  // Method descriptor #23 (Ljava/lang/Object;)V
  // Stack: 2, Locals: 1
  private static synthetic void lambda$main$0(java.lang.Object s);
    0  getstatic java.lang.System.out : java.io.PrintStream [5]
    3  aload_0 [s]
    4  invokevirtual java.io.PrintStream.println(java.lang.Object) : void [6]
    7  return
      Line numbers:
        [pc: 0, line: 8]
      Local variable table:
        [pc: 0, pc: 8] local: s index: 0 type: java.lang.Object

  Inner classes:
    [inner class info: #58 java/lang/invoke/MethodHandles$Lookup, outer class info: #62 java/lang/invoke/MethodHandles
     inner name: #59 Lookup, accessflags: 25 public static final]
Bootstrap methods:
  0 : # 30 invokestatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
    Method arguments:
        #31 (Ljava/lang/Object;)V
        #32 invokestatic TEST.lambda$main$0:(Ljava/lang/Object;)V
        #31 (Ljava/lang/Object;)V
}

大家可能想知道Java编译器如何在幕后实现lambda表达式和方法引用，以及Java虚拟机（JVM）如何处理它们。例如，lambda表达式只是匿名内部类的语法糖吗？毕竟，可以通过将lambda表达式的主体复制到匿名类的相应方法的主体中来翻译上面的代码

int total = invoices.stream()
                    .filter(new Predicate<Invoice>() {
                        @Override
                        public boolean test(Invoice inv) {
                            return inv.getMonth() == Month.JULY;
                        }
                    })
                    .mapToInt(new ToIntFunction<Invoice>() {
                        @Override
                        public int applyAsInt(Invoice inv) {
                            return inv.getAmount();
                        }
                    })
                    .sum();

本文将解释为什么Java编译器不遵循这种机制，并将阐明lambda表达式和方法引用是如何实现的。我们将研究字节码生成，并在实验室中简要分析lambda性能。最后，我们将讨论现实世界中的性能影响。

匿名内部类

匿名内部类具有可能影响应用程序性能的不良特征。

首先，编译器为每个匿名内部类生成一个新的类文件。文件名通常看起来像ClassName$1，其中ClassName是定义匿名内部类的类的名称，后跟一个美元符号和一个数字。生成许多类文件是不可取的，因为每个类文件在使用之前都需要加载和验证，这会影响应用程序的启动性能。加载可能是一项昂贵的操作，包括磁盘I/O和解压缩JAR文件本身。

如果将lambda转换为匿名内部类，则每个lambda都会有一个新的类文件。由于每个匿名内部类都将被加载，因此它将占用JVM元空间的空间（这是永久生成的Java8替代品）。如果JVM将每个匿名内部类中的代码编译成机器代码，那么它将存储在代码缓存中。此外，这些匿名内部类将被实例化为单独的对象。因此，匿名内部类会增加应用程序的内存消耗。引入缓存机制以减少所有这些内存开销可能会有所帮助，这促使引入某种抽象层。

最重要的是，从第一天起选择使用匿名内部类实现lambda将限制未来lambda实现更改的范围，以及它们根据未来JVM改进而发展的能力。

让我们看一下以下代码：

import java.util.function.Function;
public class AnonymousClassExample {
    Function<String, String> format = new Function<String, String>() {
        public String apply(String input){
            return Character.toUpperCase(input.charAt(0)) + input.substring(1);
        }
    };
}

我们可以使用命令检查为任何类文件生成的字节码

javap -c -v ClassName

为作为匿名内部类创建的函数生成的相应字节码如下所示：

0: aload_0       
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: aload_0       
5: new           #2 // class AnonymousClassExample$1
8: dup           
9: aload_0       
10: invokespecial #3 // Method AnonymousClass$1."<init>":(LAnonymousClassExample;)V
13: putfield      #4 // Field format:Ljava/util/function/Function;
16: return  

此代码显示以下内容：

• 5：使用字节码操作new实例化匿名类示例$1类型的对象。同时在堆栈上推送对新创建对象的引用。
• 8：dup操作在堆栈上复制该引用。
• 10：然后，该值由invokespecial指令使用，该指令初始化匿名内部类实例。
• 13：堆栈顶部现在仍然包含对对象的引用，该引用使用putfield指令存储在AnonymousClassExample类的format字段中。

AnonymousClassExample1类文件，您将找到函数接口实现的代码。

将lambda表达式转换为匿名内部类将限制未来可能的优化（例如缓存），因为它们与匿名内部类字节码生成机制相关联。因此，语言和JVM工程师需要一个稳定的二进制表示，该表示提供了足够的信息，同时允许JVM在将来使用其他可能的实现策略。下一节将解释这是如何实现的！

Lambdas和Invokedynamic

为了解决上一节中解释的问题，Java语言和JVM工程师决定将转换策略的选择推迟到运行时。Java7引入的新invokedynamic字节码指令为他们提供了一种高效实现这一点的机制。lambda表达式到字节码的转换分两步执行：

生成一个invokedynamic调用站点（称为lambda工厂），调用该站点时，该站点返回lambda正在转换到的功能接口的实例；
将lambda表达式体转换为将通过invokedynamic指令调用的方法。
为了说明第一步，让我们检查编译包含lambda表达式的简单类时生成的字节码，例如：

import java.util.function.Function;

public class Lambda {
    Function<String, Integer> f = s -> Integer.parseInt(s);
}
这将转换为以下字节码：

0: aload_0
 1: invokespecial #1 // Method java/lang/Object."<init>":()V
 4: aload_0
 5: invokedynamic #2, 0 // InvokeDynamic
                  #0:apply:()Ljava/util/function/Function;
10: putfield #3 // Field f:Ljava/util/function/Function;
13: return

请注意，方法引用的编译方式略有不同，因为javac不需要生成合成方法，可以直接引用该方法。

第二步的执行方式取决于lambda表达式是非捕获（lambda不访问在其主体外部定义的任何变量）还是捕获（lambda访问在其主体外部定义的变量）。

非捕获lambda被简单地分解为一个静态方法，该方法具有与lambda表达式完全相同的签名，并在使用lambda表达式的同一类中声明。例如，可以将上面lambda类中声明的lambda表达式分解为如下方法：

static Integer lambda$1(String s) {
    return Integer.parseInt(s);
}

注意：$1不是一个内部类，它只是我们表示编译器生成代码的方式

捕获lambda表达式的情况稍微复杂一些，因为捕获的变量必须与lambda的形式参数一起传递给实现lambda表达式主体的方法。在这种情况下，常见的转换策略是在lambda表达式的参数前面加上每个捕获变量的附加参数。让我们看一个实际的例子：

int offset = 100;
Function<String, Integer> f = s -> Integer.parseInt(s) + offset; 

相应的方法实现可以通过asy生成：

static Integer lambda$1(int offset, String s) {
    return Integer.parseInt(s) + offset;
}

然而，这种转换策略并不是一成不变的，因为invokedynamic指令的使用使编译器能够灵活地在将来选择不同的实现策略。例如，捕获的值可以装箱到数组中，或者，如果lambda表达式读取使用它的类的某些字段，则生成的方法可以是实例方法，而不是声明为静态的，从而避免将这些字段作为附加参数传递。

性能表现

这种方法的主要优点是性能特性。如果把它们看作是可以简化为一个数字，那就太好了，但实际上这里涉及到多个操作。

第一步是联动步骤，与上述lambda工厂步骤相对应。如果我们将性能与匿名内部类进行比较，那么等效的操作将是匿名内部类的类加载。Oracle已经发布了Sergey Kuksenko对这一权衡的性能分析，您可以看到Kuksenko在2013年JVM语言峰会上就这一主题发表了演讲[3]。分析表明，需要时间来预热lambda工厂方法，在此过程中，初始速度较慢。当有足够多的调用站点链接时，如果代码位于热路径上（即调用频率足以编译JIT的路径），则性能与类加载一致。另一方面，如果是冷路径，lambda工厂方法可以快100倍。

第二步是从周围范围捕获变量。正如我们已经提到的，如果没有要捕获的变量，那么可以自动优化此步骤，以避免使用基于lambda工厂的实现分配新对象。在匿名内部类方法中，我们将实例化一个新对象。为了优化等效情况，您必须通过创建单个对象并将其提升到静态字段来手动优化代码。例如：

// Hoisted Function
public static final Function<String, Integer> parseInt = new Function<String, Integer>() {
    public Integer apply(String arg) {
        return Integer.parseInt(arg);
    }
}; 

// Usage:
int result = parseInt.apply(“123”);
第三步是调用实际方法。目前，匿名内部类和lambda表达式都执行完全相同的操作，因此这里的性能没有差异。非捕获lambda表达式的开箱即用性能已经领先于提升的匿名内部类。捕获lambda表达式的实现与分配匿名内部类以捕获这些字段的性能类似。

我们在本节中看到，lambda表达式的实现大体上表现良好。虽然匿名内部类需要手动优化以避免分配，但JVM已经为我们优化了最常见的情况（一个不捕获其参数的lambda表达式）。

当然，理解整体性能模型是很好的，但是在实践中，事情是如何叠加的呢？我们已经在一些软件项目中使用了Java8，并取得了积极的成果。自动优化非捕获lambda可以提供很好的好处。这里有一个特别的例子，它提出了一些关于未来优化方向的有趣问题。

所讨论的示例发生在处理某些代码以供系统使用时，该系统需要特别低的GC暂停，理想情况下没有。因此，希望避免分配太多的对象。该项目广泛使用lambdas来实现回调处理程序。不幸的是，我们仍然有相当多的回调，其中我们没有捕获局部变量，但希望引用当前类的字段，甚至只调用当前类上的方法。目前，这似乎仍然需要分配。下面是一个代码示例，旨在阐明我们所讨论的内容：

public MessageProcessor() {} 

public int processMessages() {
    return queue.read(obj -> {
        if (obj instanceof NewClient) {
            this.processNewClient((NewClient) obj);
        } 
        ...
    });
}

这个问题有一个简单的解决办法。我们将代码提升到构造函数中，并将其分配给一个字段，然后在调用站点直接引用该字段。下面是我们之前重写的代码示例：

private final Consumer<Msg> handler; 

public MessageProcessor() {
    handler = obj -> {
        if (obj instanceof NewClient) {
            this.processNewClient((NewClient) obj);
        }
        ...
    };
} 

public int processMessages() {
    return queue.read(handler);
}

在所讨论的项目中，这是一个严重的问题：内存分析显示，此模式负责前八个对象分配站点中的六个，以及应用程序总分配的60%以上。

与任何潜在的优化一样，无论环境如何，应用这种方法都可能会带来其他问题。

您选择编写非惯用代码纯粹是出于性能原因。因此有一个可读性权衡

这也关系到分配的权衡。您正在向MessageProcessor添加一个字段，使其更大，以便分配。相关lambda的创建和捕获也会减慢对MessageProcessor的构造函数调用。

我们不是通过寻找场景，而是通过内存分析发现了这种情况，并且有一个很好的业务用例证明了优化的合理性。我们还处于这样一个位置：对象只分配一次，大量重用lambda表达式，因此缓存非常有益。与任何性能调整练习一样，通常推荐使用科学方法。

这也是任何其他最终用户寻求优化其lambda表达式使用的方法。尝试编写干净、简单且功能强大的代码始终是最好的第一步。任何优化，如本次吊装，应仅针对真正的问题进行。编写捕获分配对象的lambda表达式本身并不坏——正如编写调用'new Foo（）‘的Java代码本身也不坏一样。

这一经验也确实表明，要充分利用lambda表达式，重要的是要习惯地使用它们。如果lambda表达式用于表示小的纯函数，则它们几乎不需要从其周围范围捕获任何内容。和大多数事情一样，如果你保持简单，事情就会表现得很好。

数组操作

这部分包括了arrayBaseOffset（获取数组第一个元素的偏移地址）、arrayIndexScale（获取数组中元素的增量地址）等方法。arrayBaseOffset与arrayIndexScale配合起来使用，就可以定位数组中每个元素在内存中的位置。

由于Java的数组最大值为Integer.MAX_VALUE，使用Unsafe类的内存分配方法可以实现超大数组。实际上这样的数据就可以认为是C数组，因此需要注意在合适的时间释放内存。

这部分主要介绍与数据操作相关的arrayBaseOffset与arrayIndexScale这两个方法，两者配合起来使用，即可定位数组中每个元素在内存中的位置。

//返回数组中第一个元素的偏移地址
public native int arrayBaseOffset(Class<?> arrayClass);
//返回数组中一个元素占用的大小
public native int arrayIndexScale(Class<?> arrayClass);
####典型应用

这两个与数据操作相关的方法，在java.util.concurrent.atomic 包下的AtomicIntegerArray（可以实现对Integer数组中每个元素的原子性操作）中有典型的应用，如下图AtomicIntegerArray源码所示，通过Unsafe的arrayBaseOffset、arrayIndexScale分别获取数组首元素的偏移地址base及单个元素大小因子scale。后续相关原子性操作，均依赖于这两个值进行数组中元素的定位，getAndAccumulate方法即通过checkedByteOffset方法获取某数组元素的偏移地址，而后通过CAS实现原子性操作。

    private static final long serialVersionUID = 2862133569453604235L;

    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final int base = unsafe.arrayBaseOffset(int[].class);
    private static final int shift;
    private final int[] array;

    static {
        int scale = unsafe.arrayIndexScale(int[].class);
        if ((scale & (scale - 1)) != 0)
            throw new Error("data type scale not a power of two");
        shift = 31 - Integer.numberOfLeadingZeros(scale);
    }


    public final int getAndAccumulate(int i, int x,
                                      IntBinaryOperator accumulatorFunction) {
        long offset = checkedByteOffset(i);
        int prev, next;
        do {
            prev = getRaw(offset);
            next = accumulatorFunction.applyAsInt(prev, x);
        } while (!compareAndSetRaw(offset, prev, next));
        return prev;
    }

多线程同步。包括锁机制、CAS操作等。

这部分包括了monitorEnter、tryMonitorEnter、monitorExit、compareAndSwapInt、compareAndSwap等方法。

其中monitorEnter、tryMonitorEnter、monitorExit已经被标记为deprecated，不建议使用。

Unsafe类的CAS操作可能是用的最多的，它为Java的锁机制提供了一种新的解决办法，比如AtomicInteger等类都是通过该方法来实现的。compareAndSwap方法是原子的，可以避免繁重的锁机制，提高代码效率。这是一种乐观锁，通常认为在大部分情况下不出现竞态条件，如果操作失败，会不断重试直到成功。
CAS在java.util.concurrent.atomic相关类、Java AQS、CurrentHashMap等实现上有非常广泛的应用。如下图所示，AtomicInteger的实现中，静态字段valueOffset即为字段value的内存偏移地址，valueOffset的值在AtomicInteger初始化时，在静态代码块中通过Unsafe的objectFieldOffset方法获取。在AtomicInteger中提供的线程安全方法中，通过字段valueOffset的值可以定位到AtomicInteger对象中value的内存地址，从而可以根据CAS实现对value字段的原子操作。

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final long serialVersionUID = 6214790243416807050L;

    // setup to use Unsafe.compareAndSwapInt for updates
    private static final Unsafe unsafe = Unsafe.getUnsafe();
    private static final long valueOffset;

    static {
        try {
            valueOffset = unsafe.objectFieldOffset
                (AtomicInteger.class.getDeclaredField("value"));
        } catch (Exception ex) { throw new Error(ex); }
    }

...

下图为某个AtomicInteger对象自增操作前后的内存示意图，对象的基地址baseAddress="0x110000"，通过baseAddress+valueOffset得到value的内存地址valueAddress="0x11000c"；然后通过CAS进行原子性的更新操作，成功则返回，否则继续重试，直到更新成功为止。

image.png

挂起与恢复。

这部分包括了park、unpark等方法。

将一个线程进行挂起是通过park方法实现的，调用 park后，线程将一直阻塞直到超时或者中断等条件出现。unpark可以终止一个挂起的线程，使其恢复正常。整个并发框架中对线程的挂起操作被封装在 LockSupport类中，LockSupport类中有各种版本pack方法，但最终都调用了Unsafe.park()方法。
这部分，包括线程挂起、恢复、锁机制等方法。

//取消阻塞线程
public native void unpark(Object thread);
//阻塞线程
public native void park(boolean isAbsolute, long time);
//获得对象锁（可重入锁）
@Deprecated
public native void monitorEnter(Object o);
//释放对象锁
@Deprecated
public native void monitorExit(Object o);
//尝试获取对象锁
@Deprecated
public native boolean tryMonitorEnter(Object o);

如上源码说明中，方法park、unpark即可实现线程的挂起与恢复，将一个线程进行挂起是通过park方法实现的，调用park方法后，线程将一直阻塞直到超时或者中断等条件出现；unpark可以终止一个挂起的线程，使其恢复正常。

典型应用

Java锁和同步器框架的核心类AbstractQueuedSynchronizer，就是通过调用LockSupport.park()和LockSupport.unpark()实现线程的阻塞和唤醒的，而LockSupport的park、unpark方法实际是调用Unsafe的park、unpark方式来实现
七、内存屏障。

这部分包括了loadFence、storeFence、fullFence等方法。这是在Java 8新引入的，用于定义内存屏障，避免代码重排序。

loadFence() 表示该方法之前的所有load操作在内存屏障之前完成。同理storeFence()表示该方法之前的所有store操作在内存屏障之前完成。fullFence()表示该方法之前的所有load、store操作在内存屏障之前完成。
在Java 8中引入，用于定义内存屏障（也称内存栅栏，内存栅障，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作），避免代码重排序。

//内存屏障，禁止load操作重排序。屏障前的load操作不能被重排序到屏障后，屏障后的load操作不能被重排序到屏障前
public native void loadFence();
//内存屏障，禁止store操作重排序。屏障前的store操作不能被重排序到屏障后，屏障后的store操作不能被重排序到屏障前
public native void storeFence();
//内存屏障，禁止load、store操作重排序
public native void fullFence();

典型应用

在Java 8中引入了一种锁的新机制——StampedLock，它可以看成是读写锁的一个改进版本。StampedLock提供了一种乐观读锁的实现，这种乐观读锁类似于无锁的操作，完全不会阻塞写线程获取写锁，从而缓解读多写少时写线程“饥饿”现象。由于StampedLock提供的乐观读锁不阻塞写线程获取读锁，当线程共享变量从主内存load到线程工作内存时，会存在数据不一致问题，所以当使用StampedLock的乐观读锁时，StampedLock 一个原生的例子为

  class Point {
    private double x, y;
    private final StampedLock sl = new StampedLock();
 
    void move(double deltaX, double deltaY) { // an exclusively locked method
      long stamp = sl.writeLock();
      try {
        x += deltaX;
        y += deltaY;
      } finally {
        sl.unlockWrite(stamp);
      }
    }
 
    double distanceFromOrigin() { // A read-only method
      long stamp = sl.tryOptimisticRead();
      double currentX = x, currentY = y;
      if (!sl.validate(stamp)) {
         stamp = sl.readLock();
         try {
           currentX = x;
           currentY = y;
         } finally {
            sl.unlockRead(stamp);
         }
      }
      return Math.sqrt(currentX  currentX + currentY  currentY);
    }
 
    void moveIfAtOrigin(double newX, double newY) { // upgrade
      // Could instead start with optimistic, not read mode
      long stamp = sl.readLock();
      try {
        while (x == 0.0 && y == 0.0) {
          long ws = sl.tryConvertToWriteLock(stamp);
          if (ws != 0L) {
            stamp = ws;
            x = newX;
            y = newY;
            break;
          }
          else {
            sl.unlockRead(stamp);
            stamp = sl.writeLock();
          }
        }
      } finally {
        sl.unlock(stamp);
      }
    }
  }}

需要StampedLock.validate方法的源码实现，通过锁标记与相关常量进行位运算、比较来校验锁状态，在校验逻辑之前，会通过Unsafe的loadFence方法加入一个load内存屏障，目的是避免上图用例中步骤②和StampedLock.validate中锁状态校验运算发生重排序导致锁状态校验不准确的问题。

    public boolean validate(long stamp) {
        U.loadFence();
        return (stamp & SBITS) == (state & SBITS);
    }