synchronized

synchronized 实现了原子性、可见性以及有序性。

  • 原子性：一个或多个操作要么全部执行成功，要么全部执行失败。synchronized关键字可以保证只有一个线程拿到锁，访问共享资源。（volatile没有原子性，java一条代码可能对应多个cpu指令，上下文切换时可能带来原子性问题）
  • 可见性：当一个线程对共享变量进行修改后，其他线程可以立刻看到。执行synchronized时，会对应执行 lock、unlock原子操作，保证可见性。
  • 有序性：程序的执行顺序会按照代码的先后顺序执行，不禁止指令重排。

synchronized主要有三种使用方式：修饰普通同步方法、修饰静态同步方法、修饰同步方法块。

synchronized关键字可以实现什么类型的锁？

  • 悲观锁：synchronized关键字实现的是悲观锁，每次访问共享资源时都会上锁。
  • 非公平锁：synchronized关键字实现的是非公平锁，即线程获取锁的顺序并不一定是按照线程阻塞的顺序。
  • 可重入锁：synchronized关键字实现的是可重入锁，即已经获取锁的线程可以再次获取锁。
  • 独占锁或者排他锁：synchronized关键字实现的是独占锁，即该锁只能被一个线程所持有，其他线程均被阻塞。

设计同步器的意义

多线程编程中，有可能会出现多个线程同时访问同一个共享、可变资源的情况，这个资源我们称之其为临界资源；这种资源可能是：对象、变量、文件等。
共享：资源可以由多个线程同时访问
可变：资源可以在其生命周期内被修改
引出的问题：
由于线程执行的过程是不可控的，所以需要采用同步机制来协同对对象可变状态的访问！
如何解决线程并发安全问题？
实际上，所有的并发模式在解决线程安全问题时，采用的方案都是序列化访问临界资源。即在同一时刻，只能有一个线程访问临界资源，也称作同步互斥访问。
Java 中，提供了两种方式来实现同步互斥访问：synchronized 和 Lock
同步器的本质就是加锁
加锁目的：序列化访问临界资源，即同一时刻只能有一个线程访问临界资源(同步互斥访问)
不过有一点需要区别的是：当多个线程执行一个方法时，该方法内部的局部变量并不是临界资源，因为这些局部变量是在每个线程的私有栈中，因此不具有共享性，不会导致线程安全问题。

synchronized原理详解

synchronized内置锁是一种对象锁(锁的是对象而非引用)，作用粒度是对象，可以用来实现对临界资源的同步互斥访问，是可重入的。
加锁的方式：
1、同步实例方法，锁是当前实例对象
2、同步类方法，锁是当前类对象
3、同步代码块，锁是括号里面的对象
synchronized底层原理
image.png
jdk1.6以前，synchronized锁的性能比较低，故出现了基于AQS的ReentrankLock，其具有可重入性且能实现公平性。
synchronized是基于JVM内置锁实现，通过内部对象Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步，监视器锁的实现依赖底层操作系统的Mutex lock（互斥锁）实现，它是一个重量级锁性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销，内置锁的并发性能已经基本与Lock持平。
synchronized关键字被编译成字节码后会被翻译成monitorenter 和 monitorexit 两条指令分别在同步块逻辑代码的起始位置与结束位置。
synchronized - 图2
每个同步对象都有一个自己的Monitor(监视器锁)，加锁过程如下图所示：
synchronized - 图3

Monitor监视器锁
任何一个对象都有一个Monitor与之关联，当且一个Monitor被持有后，它将处于锁定状态。Synchronized在JVM里的实现都是 基于进入和退出Monitor对象来实现方法同步和代码块同步，虽然具体实现细节不一样，但是都可以通过成对的MonitorEnter和MonitorExit指令来实现。

  • monitorenter：每个对象都是一个监视器锁（monitor）。当monitor被占用时就会处于锁定状态，线程执行monitorenter指令时尝试获取monitor的所有权，过程如下：
    1. 如果monitor的进入数为0，则该线程进入monitor，然后将进入数设置为1，该线程即为monitor的所有者；
    2. 如果线程已经占有该monitor，只是重新进入，则进入monitor的进入数加1；
    3. 如果其他线程已经占用了monitor，则该线程进入阻塞状态，直到monitor的进入数为0，再重新尝试获取monitor的所有权；
  • monitorexit：执行monitorexit的线程必须是objectref所对应的monitor的所有者。指令执行时，monitor的进入数减1，如果减1后进入数为0，那线程退出monitor，不再是这个monitor的所有者。其他被这个monitor阻塞的线程可以尝试去获取这个 monitor 的所有权。

monitorexit，指令出现了两次，第1次为同步正常退出释放锁；第2次为发生异步退出释放锁；
通过上面两段描述，我们应该能很清楚的看出Synchronized的实现原理，Synchronized的语义底层是通过一个monitor的对象来完成，其实wait/notify等方法也依赖于monitor对象，这就是为什么只有在同步的块或者方法中才能调用wait/notify等方法，否则会抛出java.lang.IllegalMonitorStateException的异常的原因。
看一个同步方法：

  1. package it.yg.juc.sync;
  2. public class SynchronizedMethod {
  3.     public synchronized void method() {
  4.         System.out.println("Hello World!");
  5.     }
  6. }

反编译结果：
synchronized - 图4
从编译的结果来看，方法的同步并没有通过指令 monitorenter 和 monitorexit 来完成（理论上其实也可以通过这两条指令来实现），不过相对于普通方法，其常量池中多了 ACC_SYNCHRONIZED 标示符。JVM就是根据该标示符来实现方法的同步的：
当方法调用时，调用指令将会检查方法的 ACC_SYNCHRONIZED 访问标志是否被设置，如果设置了，执行线程将先获取monitor，获取成功之后才能执行方法体，方法执行完后再释放monitor。在方法执行期间，其他任何线程都无法再获得同一个monitor对象。
两种同步方式本质上没有区别，只是方法的同步是一种隐式的方式来实现，无需通过字节码来完成。两个指令的执行是JVM通过调用操作系统的互斥原语mutex来实现，被阻塞的线程会被挂起、等待重新调度，会导致“用户态和内核态”两个态之间来回切换，对性能有较大影响。

monitor

可以把它理解为 一个同步工具，也可以描述为 一种同步机制，它通常被 描述为一个对象。与一切皆对象一样，所有的Java对象是天生的Monitor，每一个Java对象都有成为Monitor的潜质，因为在Java的设计中 ，每一个Java对象自打娘胎里出来就带了一把看不见的锁，它叫做内部锁或者Monitor锁。也就是通常说Synchronized的对象锁，MarkWord锁标识位为10，其中指针指向的是Monitor对象的起始地址。在Java虚拟机（HotSpot）中，Monitor是由ObjectMonitor实现的，其主要数据结构如下（位于HotSpot虚拟机源码ObjectMonitor.hpp文件，C++实现的）：

  1. ObjectMonitor() {
  2.     _header       = NULL;
  3.     _count        = 0; // 记录个数
  4.     _waiters      = 0,
  5.     _recursions   = 0;
  6.     _object       = NULL;
  7.     _owner        = NULL;
  8.     _WaitSet      = NULL; // 处于wait状态的线程，会被加入到_WaitSet
  9.     _WaitSetLock  = 0 ;
  10.     _Responsible  = NULL ;
  11.     _succ         = NULL ;
  12.     _cxq          = NULL ;
  13.     FreeNext      = NULL ;
  14.     _EntryList    = NULL ; // 处于等待锁block状态的线程，会被加入到该列表
  15.     _SpinFreq     = 0 ;
  16.     _SpinClock    = 0 ;
  17.     OwnerIsThread = 0 ;
  18.   }

synchronized底层

synchronized 底层对应的 JVM 模型为 objectMonitor，使用了3个双向链表来存放被阻塞的线程：_cxq（Contention queue）、_EntryList（EntryList）、_WaitSet（WaitSet）。
当线程获取锁失败进入阻塞后，首先会被加入到 _cxq 链表，_cxq 链表的节点会在某个时刻被进一步转移到 _EntryList 链表。
当持有锁的线程释放锁后，_EntryList 链表头结点的线程会被唤醒，该线程称为 successor（假定继承者），然后该线程会尝试抢占锁。
当我们调用 wait() 时，线程会被放入 _WaitSet，直到调用了 notify()/notifyAll() 后，线程才被重新放入 _cxq 或 _EntryList，默认放入 _cxq 链表头部。

  2. ObjectMonitor() {
  3.    _header = NULL;
  4.    _count = 0; //记录个数
  5.    _waiters = 0,
  6.    _recursions = 0;
  7.    _object = NULL;
  8.    _owner = NULL;
  9.    _WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet
  10.    _WaitSetLock = 0 ;
  11.    _Responsible = NULL ;
  12.    _succ = NULL ;
  13.    _cxq = NULL ;
  14.    FreeNext = NULL ;
  15.    _EntryList = NULL ; //处于等待锁block状态的线程，会被加入到该列表
  16.    _SpinFreq = 0 ;
  17.    _SpinClock = 0 ;
  18.    OwnerIsThread = 0 ;
  19. }

objectMonitor 的整体流程如下图：
image.png

对象的内存布局

HotSpot虚拟机中，对象在内存中存储的布局可以分为三块区域：对象头（Header）、实例数据（Instance Data）和对齐填充（Padding）。

  • 对象头：比如 hash码，对象所属的年代，对象锁，锁状态标志，偏向锁（线程）ID，偏向时间，数组长度（数组对象）等。Java对象头一般占有2个机器码（在32位虚拟机中，1个机器码等于4字节，也就是32bit，在64位虚拟机中，1个机器码是8个字节，也就是64bit），但是 如果对象是数组类型，则需要3个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
  • 实例数据：存放类的属性数据信息，包括父类的属性信息；
  • 对齐填充：由于虚拟机要求 对象起始地址必须是8字节的整数倍。填充数据不是必须存在的，仅仅是为了字节对齐；

synchronized - 图6

对象头

HotSpot虚拟机的对象头包括两部分信息，第一部分是“Mark Word”，用于存储对象自身的运行时数据， 如哈希码（HashCode）、GC分代年龄、锁状态标志、线程持有的锁、偏向线程ID、偏向时间戳等等，它是实现轻量级锁和偏向锁的关键。，这部分数据的长度在32位和64位的虚拟机（暂 不考虑开启压缩指针的场景）中分别为32个和64个Bits，官方称它为“Mark Word”。对象需要存储的运行时数据很多，其实已经超出了32、64位Bitmap结构所能记录的限度，但是对象头信息是与对象自身定义的数据无关的额 外存储成本，考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存储尽量多的信息，它会根据对象的状态复用自己的存储空间。例如在32位的HotSpot虚拟机 中对象未被锁定的状态下，Mark Word的32个Bits空间中的25Bits用于存储对象哈希码（HashCode），4Bits用于存储对象分代年龄，2Bits用于存储锁标志位，1Bit固定为0，在其他状态（轻量级锁定、重量级锁定、GC标记、可偏向）下对象的存储内容如下表所示。
但是如果对象是数组类型，则需要三个机器码，因为JVM虚拟机可以通过Java对象的元数据信息确定Java对象的大小，但是无法从数组的元数据来确认数组的大小，所以用一块来记录数组长度。
对象头信息是与对象自身定义的数据无关的额外存储成本，但是考虑到虚拟机的空间效率，Mark Word被设计成一个非固定的数据结构以便在极小的空间内存存储尽量多的数据，它会根据对象的状态复用自己的存储空间，也就是说，Mark Word会随着程序的运行发生变化。
变化状态如下：
32位虚拟机

锁状态 25bit 4bit 1bit 2bit
23bit 2bit 是否偏向锁（是否禁用偏向） 锁标志位
无锁态 对象的hashCode 分代年龄 0 01
轻量级锁 指向栈中锁记录的指针 00
重量级锁 指向Monitor的指针 10
GC标记 空 11
偏向锁 线程ID Epoch 分代年龄 1 01

64位虚拟机
synchronized - 图7
锁升级过程中，分代年龄等不是消失了，而是拷贝到其它对象里了。
synchronized - 图8

在图中，提到了拷贝object mark word，由于脱离了原始mark word，官方将它冠以displaced前缀，即displaced mark word(置换标记字)。
这个displaced mark word是整个轻量级锁实现的关键，在CAS中的compare就需要用它作为条件。
为什么要拷贝mark word？
其实很简单，原因是为了不想在lock与unlock这种底层操作上再加同步。
在拷贝完object mark word之后，JVM做了一步交换指针的操作，即流程中第一个橙色矩形框内容所述。
将object mark word里的轻量级锁指针指向lock record所在的stack指针，作用是让其他线程知道，该object monitor已被占用。
lock record里的owner指针指向object mark word的作用是为了在接下里的运行过程中，识别哪个对象被锁住了。
下图直观地描述了交换指针的操作。
synchronized - 图9
synchronized - 图10
最后一步unlock中，我们发现，JVM同样使用了CAS来验证object mark word在持有锁到释放锁之间，有无被其他线程访问。
如果其他线程在持有锁这段时间里，尝试获取过锁，则可能自身被挂起，而mark word的重量级锁指针也会被相应修改。
此时，unlock后就需要唤醒被挂起的线程。

现在我们虚拟机基本是64位的，而64位的对象头有点浪费空间,JVM默认会开启指针压缩，所以基本上也是按32位的形式记录对象头的。
手动设置-XX:+UseCompressedOops 

  1. 手动设置-XX:+UseCompressedOops

哪些信息会被压缩？
1.对象的全局静态变量(即类属性)
2.对象头信息：64位平台下，原生对象头大小为16字节，压缩后为12字节
3.对象的引用类型：64位平台下，引用类型本身大小为8字节，压缩后为4字节
4.对象数组类型：64位平台下，数组类型本身大小为24字节，压缩后16字节
在Scott oaks写的《java性能权威指南》第八章8.22节提到了当heap size堆内存大于32GB是用不了压缩指针的，对象引用会额外占用20%左右的堆空间，也就意味着要38GB的内存才相当于开启了指针压缩的32GB堆空间。
这是为什么呢？看下面引用中的红字（来自openjdk wiki：https://wiki.openjdk.java.net/display/HotSpot/CompressedOops）。32bit最大寻址空间是4GB，开启了压缩指针之后呢，一个地址寻址不再是1byte，而是8byte，因为不管是32bit的机器还是64bit的机器，java对象都是8byte对齐的，而类是java中的基本单位，对应的堆内存中都是一个一个的对象。
Compressed oops represent managed pointers (in many but not all places in the JVM) as 32-bit values which must be scaled by a factor of 8 and added to a 64-bit base address to find the object they refer to. This allows applications to address up to four billion objects (not bytes), or a heap size of up to about 32Gb. At the same time, data structure compactness is competitive with ILP32 mode.
对象头分析工具
运行时对象头锁状态分析工具JOL，他是OpenJDK开源工具包，引入下方maven依赖

  1. <dependency>
  2.     <groupId>org.openjdk.jol</groupId>
  3.     <artifactId>jol-core</artifactId>
  4.     <version>0.10</version>
  5. </dependency>

打印markword

  1. public class Test10 {
  2.     public static void main(String[] args) throws InterruptedException {
  3.         TimeUnit.SECONDS.sleep(5);//jvm是延迟启动偏向锁的,我们先等偏向锁启动，不然可能会是从无锁状态开始
  4.         T o = new T();
  5. //        int i = o.hashCode()+1;
  7.         System.out.println(ClassLayout.parseInstance(o).toPrintable());
  8.         System.out.println(o.hashCode());
  9.         System.out.println(System.identityHashCode(o));
  10.         synchronized(o){
  11.             System.out.println(ClassLayout.parseInstance(o).toPrintable());
  12.         }
  13.     }
  14. }
  15. class T{
  16.     @Override
  17.     public int hashCode() {
  18.         return 1;
  19.     }
  20. }
  21. //结果如下：

image.png
之所以位置和图不对应是因为windows系统使用的是小端模式（操作系统有大端模式和小端模式，小端输出反了）

锁的膨胀升级过程
锁的状态总共有四种，无锁状态、偏向锁、轻量级锁和重量级锁。随着锁的竞争，锁可以从偏向锁升级到轻量级锁，再升级的重量级锁，但是锁的升级是单向的，也就是说只能从低到高升级，不会出现锁的降级。从JDK 1.6 中默认是开启偏向锁和轻量级锁的，可以通过-XX:-UseBiasedLocking来禁用偏向锁。下图为锁的升级全过程：
image.png

锁的升级

在JDK1.6中，为了减少获得锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁，锁的状态变成了四种，如下图所示。锁的状态会随着竞争激烈逐渐升级，但通常情况下，锁的状态只能升级不能降级。这种只能升级不能降级的策略是为了提高获得锁和释放锁的效率(但在全局安全点（safepoint）中，执行清理任务的时候会触发尝试降级锁)。
synchronized - 图13
偏向锁
偏向锁的好处是在只有一个线程获取锁的情况下，只需要（只有第一次CAS）通过一次 CAS 操作修改 markword ，之后每次进行简单的判断即可，避免了轻量级锁每次获取释放锁时的 CAS 操作。
如果确定同步代码块会被多个线程访问或者竞争较大，可以通过 -XX:-UseBiasedLocking 参数关闭偏向锁。
偏向锁的获取流程：

  1. 检查对象头中Mark Word是否为可偏向状态，如果不是则直接升级为轻量级锁。
  2. 如果是，判断Mark Work中的线程ID是否指向当前线程，如果是，则执行同步代码块。
  3. 如果不是，则进行CAS操作竞争锁，如果竞争到锁，则将Mark Work中的线程ID设为当前线程ID，执行同步代码块。
  4. 如果竞争失败，升级为轻量级锁。

偏向锁的获取流程如下图：
image.png
cas替换Markword中的thread ID失败会升级为重量级锁。
image.png
偏向锁的撤销：
只有等到竞争，持有偏向锁的线程才会撤销偏向锁。偏向锁撤销后会恢复到无锁或者轻量级锁的状态。

  1. 偏向锁的撤销需要到达全局安全点，全局安全点表示一种状态，该状态下所有线程都处于暂停状态。
  2. 判断锁对象是否处于无锁状态，即获得偏向锁的线程如果已经退出了临界区，表示同步代码已经执行完了。重新竞争锁的线程会进行CAS操作替代原来线程的ThreadID。
  3. 如果获得偏向锁的线程还处于临界区之内，表示同步代码还未执行完，将获得偏向锁的线程升级为轻量级锁。

一句话简单总结偏向锁原理：使用CAS操作将当前线程的ID记录到对象的Mark Word中。
轻量级锁
引入轻量级锁的目的：在多线程交替执行同步代码块时（未发生竞争），避免使用互斥量（重量锁）带来的性能消耗。但多个线程同时进入临界区（发生竞争）则会使得轻量级锁膨胀为重量级锁。
轻量级锁（每次都CAS）的获取流程：

  1. 首先判断当前对象是否处于一个无锁的状态，如果是，Java虚拟机将在当前线程的栈帧建立一个锁记录（Lock Record），用于存储对象目前的Mark Word的拷贝，如图所示。
    synchronized - 图16
  2. 将对象的Mark Word复制到栈帧中的Lock Record中，并将Lock Record中的owner指向当前对象，并使用CAS操作将对象的Mark Word更新为指向Lock Record的指针，如图所示。
    synchronized - 图17
  3. 如果第二步执行成功，表示该线程获得了这个对象的锁，将对象Mark Word中锁的标志位设置为“00”，执行同步代码块。
  4. 如果第二步未执行成功，需要先判断当前对象的Mark Word是否指向当前线程的栈帧，如果是，表示当前线程已经持有了当前对象的锁，这是一次重入，直接执行同步代码块。

轻量级锁的解锁：
轻量级的解锁同样是通过CAS操作进行的，线程会通过CAS操作将Lock Record中的Mark Word（官方称为Displaced Mark Word）替换回来。如果成功表示没有竞争发生，成功释放锁，恢复到无锁的状态；如果失败，表示当前锁存在竞争，升级为重量级锁。
一句话总结轻量级锁的原理：将对象的Mark Word复制到当前线程的Lock Record中，并将对象的Mark Word更新为指向Lock Record的指针。
自旋锁
Java锁的几种状态并不包括自旋锁，当轻量级锁的竞争就是采用的自旋锁机制（升级为重量级锁）。
什么是自旋锁：当线程A已经获得锁时，线程B再来竞争锁，线程B不会直接被阻塞，而是在原地循环 等待，当线程A释放锁后，线程B可以马上获得锁。
引入自旋锁的原因：因为阻塞和唤起线程都会引起操作系统用户态和核心态的转变，对系统性能影响较大，而自旋等待可以避免线程切换的开销。
自旋锁的缺点：自旋等待虽然可以避免线程切花的开销，但它也会占用处理器的时间。如果持有锁的线程在较短的时间内释放了锁，自旋锁的效果就比较好，如果持有锁的线程很长时间都不释放锁，自旋的线程就会白白浪费资源，所以一般线程自旋的次数必须有一个限制，该次数可以通过参数-XX:PreBlockSpin调整，一般默认为10。
自适应自旋锁：JDK1.6引入了自适应自旋锁，自适应自旋锁的自旋次数不在固定，而是由上一次在同一个锁上的自旋时间及锁的拥有者的状态来决定的。如果对于某个锁对象，刚刚有线程自旋等待成功获取到锁，那么虚拟机将认为这次自旋等待的成功率也很高，会允许线程自旋等待的时间更长一些。如果对于某个锁对象，线程自旋等待很少成功获取到锁，那么虚拟机将会减少线程自旋等待的时间。
偏向锁、轻量级锁、重量级锁的对比

锁 优点 缺点 实用场景
偏向锁 加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距 如果线程间存在竞争，会额外带来锁撤销的消耗 适用于只有一个线程访问同步块场景
轻量级锁 竞争的线程不会阻塞，提高了程序的响应速度 如果始终得不到锁竞争的线程，使用自旋会消耗CPU 追求响应时间，同步块执行速度非常快
重量级锁 线程竞争不使用自旋，不会消耗CPU 线程阻塞，使用了内核态的monitor会导致上下文切换，响应时间缓慢 追求吞吐量，同步块执行速度较慢

该表格出自《Java并发编程的艺术》
锁粗化
合并多个连续的锁，使得需要同步的操作数量尽可能变少，即使存在锁竞争，等待锁的线程也能尽可能快地拿到锁。
锁消除
消除锁是虚拟机另外一种锁的优化，这种优化更彻底，Java虚拟机在JIT编译时(可以简单理解为当某段代码即将第一次被执行时进行编译，又称即时编译)，通过对运行上下文的扫描，去除不可能存在共享资源竞争的锁，通过这种方式消除没有必要的锁，可以节省毫无意义的请求锁时间，如下StringBuffer的append是一个同步方法，但是在add方法中的StringBuffer属于一个局部变量，并且不会被其他线程所使用，因此StringBuffer不可能存在共享资源竞争的情景，JVM会自动将其锁消除。锁消除的依据是逃逸分析的数据支持。
锁消除，前提是java必须运行在server模式（server模式会比client模式作更多的优化），同时必须开启逃逸分析
:-XX:+DoEscapeAnalysis 开启逃逸分析
-XX:+EliminateLocks 表示开启锁消除。
逃逸分析
在编程语言的编译优化原理中，分析指针动态范围的方法称之为逃逸分析。通俗一点讲，当一个对象的指针被多个方法或线程引用时，我们称这个指针发生了逃逸。
而用来分析这种逃逸现象的方法，就称之为逃逸分析。
使用逃逸分析，编译器可以对代码做如下优化：
一、同步省略。如果一个对象被发现只能从一个线程被访问到，那么对于这个对象的操作可以不考虑同步。
二、将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配。
三、分离对象或标量替换。有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

是不是所有的对象和数组都会在堆内存分配空间？不一定

在Java代码运行时，通过JVM参数可指定是否开启逃逸分析， -XX:+DoEscapeAnalysis ： 表示开启逃逸分析 -XX:-DoEscapeAnalysis ： 表示关闭逃逸分析。从jdk 1.7开始已经默认开启逃逸分析，如需关闭，需要指定-XX:-DoEscapeAnalysis
逃逸案例

  1. public class T0_ObjectStackAlloc {
  2.     /**
  3.      * 进行两种测试
  4.      * 关闭逃逸分析，同时调大堆空间，避免堆内GC的发生，如果有GC信息将会被打印出来 
  5.      * VM运行参数：-Xmx4G -Xms4G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
  6.      *
  7.      * 开启逃逸分析
  8.      * VM运行参数：-Xmx4G -Xms4G -XX:+DoEscapeAnalysis -XX:+PrintGCDetails -XX:+HeapDumpOnOutOfMemoryError
  9.      *
  10.      * 执行main方法后
  11.      * jps 查看进程
  12.      * jmap -histo 进程ID
  13.      *
  14.      */
  15.     public static void main(String[] args) {
  16.         long start = System.currentTimeMillis();
  17.         for (int i = 0; i < 500000; i++) {
  18.             alloc();
  19.         }
  20.         long end = System.currentTimeMillis();
  21.         //查看执行时间
  22.         System.out.println("cost-time " + (end - start) + " ms");
  23.         try {
  24.             Thread.sleep(100000);
  25.         } catch (InterruptedException e1) {
  26.             e1.printStackTrace();
  27.         }
  28.     }
  30.     private static TulingStudent alloc() {
  31.         //Jit对编译时会对代码进行 逃逸分析
  32.         //并不是所有对象存放在堆区，有的一部分存在线程栈空间
  33.         TulingStudent student = new TulingStudent();
  34.         return student;
  35.     }
  37.     static class TulingStudent {
  38.         private String name;
  39.         private int age;
  40.     }
  41. }

结论： 关闭逃逸分析堆中会创建500000个对象，开启则部分放在线程栈中，这样可以减少GC。

wait()、sleep()、yield()、join()

1.wait()
wait 方法是属于 Object 类中的，wait 过程中线程会释放对象锁，只有当其他线程调用 notify 才能唤醒此线程。wait 使用时必须先获取对象锁，即必须在 synchronized 修饰的代码块中使用，那么相应的 notify 方法同样必须在 synchronized 修饰的代码块中使用，如果没有在synchronized 修饰的代码块中使用时运行时会抛出IllegalMonitorStateException的异常

2.sleep
sleep 方法是属于 Thread 类中的，sleep 过程中线程不会释放锁，只会阻塞线程，让出cpu给其他线程，但是他的监控状态依然保持着，当指定的时间到了又会自动恢复运行状态，可中断，sleep 给其他线程运行机会时不考虑线程的优先级，因此会给低优先级的线程以运行的机会

3.yield
和 sleep 一样都是 Thread 类的方法，都是暂停当前正在执行的线程对象，不会释放资源锁，和 sleep 不同的是 yield方法并不会让线程进入阻塞状态，而是让线程重回就绪状态，它只需要等待重新获取CPU执行时间，所以执行yield()的线程有可能在进入到可执行状态后马上又被执行（所有线程再次竞争CPU）。还有一点和 sleep 不同的是 yield 方法只能使同优先级或更高优先级的线程有执行的机会

4.join
等待调用join方法的线程结束之后，程序再继续执行，一般用于等待异步线程执行完结果之后才能继续运行的场景。例如：主线程创建并启动了子线程，如果子线程中药进行大量耗时运算计算某个数据值，而主线程要取得这个数据值才能运行，这时就要用到 join 方法了。