synchronized 的原理

synchronized修饰方法

更加准确的说法应该是修饰实例方法，而不包括静态方法。关键字synchronized取得的锁都是对象锁，而不是把一段代码或方法当作锁。原因在于，要调用一个实例方法必须要new一个对应的实例对象，通过此实例对象才能访问实例方法。要实现同步，那么不同线程的锁必须是访问的同一个对象。这也是从设计角度来讲，为何notify， wait等和锁相关的方法定义在Object这个类中，而非Thread类中的原因之一。

 如果多个线程访问多个对象，则JVM会创建多个锁。

牢记：只有共享资源的读写访问才需要同步化，如果不是共享资源那么根本就没有必要同步。

例子类 Run

1. public class Run {

2.  

3. public static void main(String[] args) {

4. //证明synchronized锁定的是对象

5. MyObject object = new MyObject();

6. ThreadA a = new ThreadA(object);

7. a.setName("A");

8. ThreadB b = new ThreadB(object);

9. b.setName("B");

10.  

11. a.start();

12. b.start();

13. }

14.  

15. }

1. public class MyObject {

2.  

3. synchronized public void methodA() {

4. //如果不加synchronized则两个线程可同时进入methodA方法。若加入synchronized，则声明的方法一定是排队运行的

5. //public void methodA() {

6. try {

7. System.out.println("begin methodA threadName="

8. + Thread.currentThread().getName());

9. Thread.sleep(5000);

10. System.out.println("end");

11. } catch (InterruptedException e) {

12. e.printStackTrace();

13. }

14. }

15.  

16. }

Thread A

1. public class ThreadA extends Thread {

2.  

3. private MyObject object;

4.  

5. public ThreadA(MyObject object) {

6. super();

7. this.object = object;

8. }

9.  

10. @Override

11. public void run() {

12. super.run();

13. object.methodA();

14. }

15.  

16. }

Thread B

1. package com.dr.mutiplethreads.chapter2.synchronizedMethodLockObject;

2.  

3. public class ThreadB extends Thread {

4.  

5. private MyObject object;

6.  

7. public ThreadB(MyObject object) {

8. super();

9. this.object = object;

10. }

11.  

12. @Override

13. public void run() {

14. super.run();

15. object.methodA();

16. }

17. }

这个例子当中，共享资源是MyObject的实例object, 而object中的方法methodA()是用synchronized修饰的，因此当一个线程执行这个方法时需要先取得对象锁，这里就是要取得object对象。
 

synchronized代码块

例子：

1. synchronized(this){

2. }

当一个线程访问某个对象的一个synchronized同步代码块时，另一个线程仍然可以访问该对象中的非synchronized(this)代码块。一半是异步，一半是同步，不在synchronized块中就是异步执行，在synchronized块中就是同步执行。

但是，synchronized持有的锁仍然是调用它的对象。

synchronized(this)代码块锁定的是当前对象。在多个线程持有对象监视器为同一个对象的前提下，同一时间只有一个线程可以执行synchronized(非this对象x)同步代码块中的代码.

但是我们可以把任何对象当作对象监视器，格式 synchronized(非this对象)，作用只有一种:synchronized(非this对象)同步代码块

static静态synchronized方法与synchronized(class)代码块对比

由于静态成员不专属于任何一个实例对象（这句话非常重要，真是因为静态成员本质上并不属于任何一个实例，因此对象锁对于它们是没有意义的，针对静态成员的并发事实上也就是多个线程之间访问同一个静态资源的并发问题），是类成员，因此通过class对象锁可以控制静态 成员的并发操作。需要注意的是如果一个线程A调用一个实例对象的非static synchronized方法，而线程B需要调用这个实例对象所属类的静态 synchronized方法，是允许的，不会发生互斥现象，因为访问静态 synchronized 方法占用的锁是当前类的class对象，而访问非静态 synchronized 方法占用的锁是当前实例对象锁.

    另外，从内存的角度来讲，静态成员所分配的内存空间也并不和任何一个对象的内存空间重叠，而是单独在一块内存里面分配。

synchronized是对类的当前实例进行加锁，防止其他线程同时访问该类的该实例的所有synchronized块，注意这里是“类的当前实例”，类的两个不同实例就没有这种约束了。那么static synchronized恰好就是要控制类的所有实例的访问了，static synchronized是限制线程同时访问jvm中该类的所有实例同时访问对应的代码快。实际上，在类中某方法或某代码块中有 synchronized，那么在生成一个该类实例后，该类也就有一个监视快，放置线程并发访问该实例synchronized保护快，而static synchronized则是所有该类的实例公用一个监视快了，也就是两个的区别了,也就是synchronized相当于this.synchronized，而staticsynchronized相当于Something.synchronized.

1. pulbic class Something(){

2. public synchronized void isSyncA(){}

3. public synchronized voidisSyncB(){}

4. public static synchronizedvoid cSyncA(){}

5. public static synchronizedvoid cSyncB(){}

6. }

 那么，假如有Something类的两个实例a与b，那么下列组方法何以被1个以上线程同时访问呢
   a.   x.isSyncA()与x.isSyncB() 
   b.   x.isSyncA()与y.isSyncA()
   c.   x.cSyncA()与y.cSyncB()
   d.   x.isSyncA()与Something.cSyncA()
    这里，很清楚的可以判断：
   a，都是对同一个实例的synchronized域访问，因此不能被同时访问
   b，是针对不同实例的，因此可以同时被访问
   c，因为是staticsynchronized，所以不同实例之间仍然会被限制,相当于Something.isSyncA()与   Something.isSyncB()了，因此不能被同时访问。

     那么，第d呢?，书上的 答案是可以被同时访问的，答案理由是synchronzied的是实例方法与synchronzied的类方法由于锁定（lock）不同的原因。

结论：

A: synchronized static是某个类的范围，synchronized static cSync{}防止多个线程同时访问这个类中的synchronized static 方法。它可以对类的所有对象实例起作用。

B: synchronized 是某实例的范围，synchronized isSync(){}防止多个线程同时访问这个实例中的synchronized 方法。

synchronized底层实现原理

要理解synchronized的底层实现原理，需要先了解java对象的内存布局，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。如下：

其中，对象头是实现synchronized的锁对象的基础。synchronized使用的锁对象是存储在Java对象头里的，Hotspot虚拟机的对象头主要包括两部分数据：Mark Word（标记字段）、Klass Pointer（类型指针）。其中Klass Point是是对象指向它的类元数据的指针，虚拟机通过这个指针来确定这个对象是哪个类的实例，Mark Word用于存储对象自身的运行时数据，它是实现轻量级锁和偏向锁的关键.

由于对象头的信息是与对象自身定义的数据没有关系的额外存储成本，因此考虑到JVM的空间效率，Mark Word 被设计成为一个非固定的数据结构，以便存储更多有效的数据，它会根据对象本身的状态复用自己的存储空间

 

synchronized不同的用法在底层的实现上并不完全一样，这一点需要特别注意。

1. 同步代码块使用monitorenter 和 monitorexit 指令来实现同步
2. 同步方法并不是由 monitorenter 和 monitorexit 指令来实现同步的，而是由方法调用指令读取运行时常量池中方法的 ACC_SYNCHRONIZED 标志来隐式实现的.

同步代码块实现原理

同步代码块是使用虚拟机的指令monitorenter和monitorexit指令实现的. monitorenter指令插入到同步代码块的开始位置，monitorexit指令插入到同步代码块的结束位置，JVM需要保证每一个monitorenter都有一个monitorexit与之相对应。任何对象都有一个monitor与之相关联，当且一个monitor被持有之后，他将处于锁定状态。线程执行到monitorenter指令时，将会尝试获取对象所对应的monitor所有权，即尝试获取对象的锁.  下面是一个同步代码块的伪代码

1. sycnchronized(this){

2.  

3. }

    其中monitor的本质是依赖于底层操作系统的Mutex Lock实现,Mutex是操作系统定义信号量的关键字，是操作系统实现同步所使用的技术，操作系统实现线程之间的切换需要从用户态到内核态的切换，切换成本非常高。

同步代码块便宜之后的字节码大致如下

1. 3: monitorenter //进入同步方法

2. //..........省略其他

3. 15: monitorexit //退出同步方法

4. 16: goto 24

5. //省略其他.......

6. 21: monitorexit //退出同步方法

   为了保证在方法异常完成时 monitorenter 和 monitorexit 指令依然可以正确配对执行，编译器会自动产生一个异常处理器，这个异 常处理器声明可处理所有的异常，它的目的就是用来执行 monitorexit 指令。从字节码中也可以看出多了一个monitorexit指令，它  就是异常结束时被执行的释放monitor 的指令。

同步方法实现原理

同步方法则是通过对象头实现的访问标志位为基础实现的。synchronized方法会被翻译成普通的方法调用和返回指令如:invokevirtual、areturn指令，在VM字节码层面并没有任何特别的指令来实现被synchronized修饰的方法，而是在Class文件的方法表中将该方法的access_flags字段中的synchronized标志位置1，表示该方法是同步方法并使用调用该方法的对象或该方法所属的Class在JVM的内部对象表示Klass做为锁对象。 下面是一个同步方法的伪代码

1. public synchronized void methodA(){

2.  

3. }

注意在JVM中，对象在内存中的布局分为三块区域：对象头、实例数据和对齐填充。详细请看：https://blog.csdn.net/javazejian/article/details/72828483. 其字节码大致如下

1. public synchronized void syncTask();

2. descriptor: ()V

3. //方法标识ACC_PUBLIC代表public修饰，ACC_SYNCHRONIZED指明该方法为同步方法

4. flags: ACC_PUBLIC, ACC_SYNCHRONIZED

5. Code:

6. stack=3, locals=1, args_size=1

从字节码中可以看出，synchronized修饰的方法并没有monitorenter指令和monitorexit指令，取得代之的确实是ACC_SYNCHRONIZED标识，该标识指明了该方法是一个同步方法，JVM通过该ACC_SYNCHRONIZED访问标志来辨别一个方法是否声明为同步方法，从而执行相应的同步调用。这便是synchronized锁在同步代码块和同步方法上实现的基本原理。

 

线程私有的变量

先上结论：

1. 静态变量：线程非安全。  静态变量即类变量，位于方法区，为所有对象共享，共享一份内存，一旦静态变量被修改，其他对象均对修改可见，故线程非安全。
2. 实例变量：单例模式（只有一个对象实例存在）线程非安全，非单例线程安全。 实例变量为对象实例私有，在虚拟机的堆中分配，若在系统中只存在一个此对象的实例，在多线程环境下，“犹如”静态变量那样，被某个线程修改后，其他线程对修改均可见，故线程非安全；如果每个线程执行都是在不同的对象中，那对象与对象之间的实例变量的修改将互不影响，故线程安全。
3. 局部变量：线程安全。 每个线程执行时将会把局部变量放在各自栈帧的工作内存中，线程间不共享，故不存在线程安全问题。

具体分析参考：https://www.cnblogs.com/firstdream/p/7976871.html

锁重入是什么？如何实现的？

锁重入是什么：

锁重入的意思就是当一个线程得到一个对象锁后，再次请求此对象锁时是可以再次得到该对象的锁的。synchronized关键字拥有锁重入的功能，在一个synchronized方法/块内部调用本对象的其他synchronized方法/块时，是永远可以得到锁的，原因是Java中线程获得对象锁的操作是以线程为单位的，而不是以调用为单位的。同一个线程获得一个对象锁之后，再次访问这个对象的其他同步方法，所需的对象锁没有发生变化。

实现逻辑：

每个锁关联一个线程持有者和一个计数器。当计数器为0时表示该锁没有被任何线程持有，那么任何线程都都可能获得该锁而调用相应方法。当一个线程请求成功后，JVM会记下持有锁的线程，并将计数器计为1。此时其他线程请求该锁，则必须等待。而该持有锁的线程如果再次请求这个锁，就可以再次拿到这个锁，同时计数器会递增。当线程退出一个synchronized方法/块时，计数器会递减，如果计数器为0则释放该锁。

Synchronized优化

jdk1.6对锁的实现引入了大量的优化，如自旋锁、适应性自旋锁、锁消除、锁粗化、偏向锁、轻量级锁等技术来减少锁操作的开销。

锁主要存在四中状态，依次是：无锁状态、偏向锁状态、轻量级锁状态、重量级锁状态，他们会随着竞争的激烈而逐渐升级。注意锁可以升级不可降级，这种策略是为了提高获得锁和释放锁的效率。

自旋锁

所谓自旋锁，就是让该线程等待一段时间，不会被立即挂起，看持有锁的线程是否会很快释放锁。怎么等待呢？执行一段无意义的循环即可（自旋）。

JDK 1.6引入了更加聪明的自旋锁，即自适应自旋锁。所谓自适应就意味着自旋的次数不再是固定的，它是由前一次在同一个锁上的自旋时间及锁的拥有者的状态来决定。它怎么做呢？线程如果自旋成功了，那么下次自旋的次数会更加多，因为虚拟机认为既然上次成功了，那么此次自旋也很有可能会再次成功，那么它就会允许自旋等待持续的次数更多。反之，如果对于某个锁，很少有自旋能够成功的，那么在以后要或者这个锁的时候自旋的次数会减少甚至省略掉自旋过程，以免浪费处理器资源。 
有了自适应自旋锁，随着程序运行和性能监控信息的不断完善，虚拟机对程序锁的状况预测会越来越准确，虚拟机会变得越来越聪明。

锁消除

为了保证数据的完整性，我们在进行操作时需要对这部分操作进行同步控制，但是在有些情况下，JVM检测到不可能存在共享数据竞争，这是JVM会对这些同步锁进行锁消除。锁消除的依据是逃逸分析的数据支持。

如果不存在竞争，为什么还需要加锁呢？所以锁消除可以节省毫无意义的请求锁的时间。变量是否逃逸，对于虚拟机来说需要使用数据流分析来确定，但是对于我们程序员来说这还不清楚么？我们会在明明知道不存在数据竞争的代码块前加上同步吗？但是有时候程序并不是我们所想的那样？我们虽然没有显示使用锁，但是我们在使用一些JDK的内置API时，如StringBuffer、Vector、HashTable等，这个时候会存在隐形的加锁操作。比如StringBuffer的append()方法，Vector的add()方法

1. public void vectorTest(){

2. Vector vector = new Vector();

3. for(int i = 0 ; i < 10 ; i++){

4. vector.add(i + "");

5. }

6.  

7. System.out.println(vector);

8. }

在运行这段代码时，JVM可以明显检测到变量vector没有逃逸出方法vectorTest()之外，所以JVM可以大胆地将vector内部的加锁操作消除。

锁粗化

我们知道在使用同步锁的时候，需要让同步块的作用范围尽可能小—仅在共享数据的实际作用域中才进行同步，这样做的目的是为了使需要同步的操作数量尽可能缩小，如果存在锁竞争，那么等待锁的线程也能尽快拿到锁

但是如果一系列的连续加锁解锁操作，可能会导致不必要的性能损耗，所以引入锁粗话的概念。

 
锁粗话概念比较好理解，就是将多个连续的加锁、解锁操作连接在一起，扩展成一个范围更大的锁。如上面实例：vector每次add的时候都需要加锁操作，JVM检测到对同一个对象（vector）连续加锁、解锁操作，会合并一个更大范围的加锁、解锁操作，即加锁解锁操作会移到for循环之外。

偏向锁

偏向锁是Java 6之后加入的新锁，它是一种针对加锁操作的优化手段，经过研究发现，在大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，因此为了减少同一线程获取锁(会涉及到一些CAS操作,耗时)的代价而引入偏向锁。偏向锁的核心思想是，如果一个线程获得了锁，那么锁就进入偏向模式，此时Mark Word 的结构也变为偏向锁结构，当这个线程再次请求锁时，无需再做任何同步操作，即获取锁的过程，这样就省去了大量有关锁申请的操作，从而也就提供程序的性能。所以，对于没有锁竞争的场合，偏向锁有很好的优化效果，毕竟极有可能连续多次是同一个线程申请相同的锁。但是对于锁竞争比较激烈的场合，偏向锁就失效了，因为这样场合极有可能每次申请锁的线程都是不相同的，因此这种场合下不应该使用偏向锁，否则会得不偿失，需要注意的是，偏向锁失败后，并不会立即膨胀为重量级锁，而是先升级为轻量级锁。

偏向锁的释放采用了一种只有竞争才会释放锁的机制，线程是不会主动去释放偏向锁，需要等待其他线程来竞争

轻量级锁

倘若偏向锁失败，虚拟机并不会立即升级为重量级锁，它还会尝试使用一种称为轻量级锁的优化手段(1.6之后加入的)，此时Mark Word 的结构也变为轻量级锁的结构。轻量级锁能够提升程序性能的依据是“对绝大部分的锁，在整个同步周期内都不存在竞争”，注意这是经验数据。需要了解的是，轻量级锁所适应的场景是线程交替执行同步块的场合，如果存在同一时间访问同一锁的场合，就会导致轻量级锁膨胀为重量级锁

引入轻量级锁的主要目的是在多没有多线程竞争的前提下，减少传统的重量级锁使用操作系统互斥量产生的性能消。

Synchronized和ReentrantLock对比

相同之处

都是加锁方式同步，而且都是阻塞式的同步，也就是说当如果一个线程获得了对象锁，进入了同步块，其他访问该同步块的线程都必须阻塞在同步块外面等待。

synchronized 与Lock都是可重入锁，同一个线程再次进入同步代码的时候.可以使用自己已经获取到的锁。

不同之处

对于Synchronized来说，它是java语言的关键字，是原生语法层面的互斥，需要jvm实现

而ReentrantLock它是JDK 1.5之后提供的API层面的互斥锁，需要lock()和unlock()方法配合try/finally语句块来完成. ReentrantLock是一个类。lock()和unlock()方法是借助Unsafe类实现的.

Synchronized是悲观锁机制，独占锁。而Locks.ReentrantLock是，每次不加锁而是假设没有冲突而去完成某项操作，如果因为冲突失败就重试，直到成功为止。

ReentrantLock类提供了一些高级功：

1. 等待可中断，持有锁的线程长期不释放的时候，正在等待的线程可以选择放弃等待，这相当于Synchronized来说可以避免出现死锁的情况。
2. 公平锁，多个线程等待同一个锁时，必须按照申请锁的时间顺序获得锁，Synchronized锁非公平锁，ReentrantLock默认的构造函数是创建的非公平锁，可以通过参数true设为公平锁，但公平锁表现的性能不是很好。
3. 锁绑定多个条件，一个ReentrantLock对象可以同时绑定对个对象。

ReentrantLock适用场景

1. 某个线程在等待一个锁的控制权的这段时间需要中断
2. 需要分开处理一些wait-notify，ReentrantLock里面的Condition应用，能够控制notify哪个线程，锁可以绑定多个条件。
3. 具有公平锁功能，每个到来的线程都将排队等候。