深入理解synchronized的原理是什么

对象头锁机制原则

Synchronized 的原理是什么

  Synchronized 是由JVM实现的一种实现互斥同步的实现方式。如果查看synchronized关键字修饰的字节码，会发现在编译器生成了monitorenter和monitorexit两个字节码指令。

  这两个指令的意思就是在虚拟机执行到monitorenter指令的时候，首先尝试获取到对象锁，对象头这部分在对象的最前端，包含两部分或者三部分：Mark Words、Klass Words，如果对象是一个数组，那么还可能包含第三部分：数组的长度。Mark Word需要重点说一下，这里面主要包含对象的哈希值、年龄分代、锁标志位等，大小为32位或64位

  如果这个对象没有锁定，或者当前线程已经拥有了这个对象锁，那么就把锁的计数器进行+1操作，当执行monitorexit指令的时候将锁计数器进行-1操作，当计数器为0的时候，锁就被释放了。
  如果获取对象失败了，当前线程就要阻塞等待，直到对象锁被另外一个线程释放。

刚刚提到的对象所，这个锁到底是什么？如何确定对象的锁？

  锁 的本质是monitorenter和monitorexit 字节码指令的一个Reference类型的参数，也就是是要锁定和解锁的对象。
  Synchronized可以修饰不同的对象，所以对应的对象锁可以通过如下的方式确定

• 1、如果Synchronized明确指定了锁定对象，说明加锁对象为该对象。
• 2、如果没有明确指定：
   如果Synchronized修饰的方法为非静态方法，表示此方法对应的对象为锁对象；
   如果Synchronized修饰的方法为静态方法，则表示这个方法对应的类对象为锁对象。

  需要注意的是，当一个对象被锁住的时候，对象里面所有用synchronized修饰的方法都将会被阻塞，而对象里非synchronized修饰方法可以正常被调用，不受到影响。

什么是可重入性，为什么synchronized是可重入锁？

  可重入性是锁的基本要求，是为了解决死锁的情况发生。

  如图所示，在一个类中同步调用了另一个同步方法，假如synchronized不支持重入，进入method2的时候当前线程获取锁，method2中又执行了method1的时候当前线程又要尝试获取锁，这个时候如果不支持重入，那就要等待释放，所以自己获取锁，自己等释放，就会导致死锁。

  对于synchronized来说，重要性是显而易见的。在执行monitorenter指令的时候 ，如果这个对象没有锁定，或者当前线程已经拥有了这对象锁，就把锁的计数器加一，实际上就是通过这种机制来实现锁重入。

JVM对于Java的原生锁做了那些优化

  在Java6之前Monitor实现完全依赖底层操作系统的互斥锁来实现，也就是在上面提到的获取/释放锁的逻辑。

  由于Java层面的线程与操作系统的原生线程有对应的映射关系，如果要将一个线程进行阻塞或者唤醒都需要操作系统线程的协助，也就是从用户态到内核态的切换，这种相互之间的切换其实是一件非常消耗内存的事情。

  所以JDK对于这种操作进行了很多的优化。

 使用自旋锁，也就是说把线程进行阻塞操作之前让线程自旋等待一段时间，可能在等待的时候其他线程已经解锁了，这个时候就不需要线程在等待了，避免了用户态到内核态的切换。

 在JDK中提供了三种不同的Monitor的实现，也就是三种不同的锁机制。

• 偏向锁
• 轻量级锁
• 重量级锁

  这三种锁机制使得JDK对于synchronized的优化进行进一步的提升，当JVM检测到不同的资源竞争状况的时候，会自动切换到合适的锁实现机制，也就是所谓的锁的升级与降级。

  当没有出现竞争的时候，默认使用的是偏向锁。

  JVM会利用CAS操作，在对象头的MarkWord部分设置线程ID，以表示这个对象偏向于当前线程，所以并不涉及真正的互斥锁，因为在很多应用场景中，大部分对象生命周期中最多会被一个线程锁定，使用偏向锁可以降低无竞争开销。

  如果有一个线程试图锁定偏向锁对象的时候，JVM就撤销偏向锁，切换到轻量级锁。

  轻量级锁通过CAS操作Mark Word来试图获取锁，如果重试成功，就使用普通的轻量级锁，否则就升级为重量级锁。

为什么说synchronized是非公平锁？

  非公平主要表现在获取锁的行为上，并非按照申请锁的时间前后给等待线程分配锁，每当锁被释放之后，任何一个线程都有机会竞争到锁，这样做的目的是为了提高执行性能，缺点是会产生线饥饿现象。

什么是锁消除和锁粗化？

• 锁消除：指虚拟机及时编译器在运行时，对一些代码上要求同步，但被检测到不可能存在共享数据竞争的锁进行消除。主要根据逃逸分析。开发者怎么会在明知道不会存在数据竞争的情况下使用同步操作呢？很多的操作其实不是开发者自己加入的。
• 锁粗化：原则上，同步块的作用范围要尽量小。但是如果一系列的连续操作都对同一个对象反复加锁和解锁，甚至加锁操作在循环体内，频繁地进行互斥同步操作也会导致不必要的性能损耗。锁粗化就是增加锁的作用域。

为什么说 synchronized是一个悲观锁？乐观锁的实现原理又是什么？什么是CAS，它有什么特性？

  synchronized是一个悲观锁，因为他的并发策略是悲观的，不管是否会产生竞争，任何的数据都必须要加锁、用户态核心态转换、维护锁计数器和检查是否有被阻塞的线程需要被唤醒等操作。

  随着硬件指令集的发展，可以使用基于冲突检测的乐观锁并发策略。先进性操作，如果没有其他线程征用数据，那么就操作成功。

  如果共享数据有被用到，产生了冲突，那就再进行其他的补偿措施。这种乐观的并发策略的许多实现不需要线程挂起，所以被称为非阻塞同步。

  乐观锁的核心算法是CAS（Compareand Swap,比较交换），涉及到三个操作数：内存值、预期值、新值。当且仅当预期值和内存值相等的时候才将内存值修改新值。

  这样处理的逻辑是，首先检查某块内存的值是否跟之前读取过的值一样，如果不一样则表示期间此内存值已经被别的线程修改过了，舍弃本次操作，否则则说明在此期间没有其他线程对此内存值进行修改，就可以直接使用该值。

  CAS具有原子性，他的原子性有CPU硬件指令实现保证，即使用JNI调用Native方法调用C++编写的硬件指令，JDK中提供了Unsafe类执行这些操作。

乐观锁一定就是好的？

  乐观锁避免了悲观锁独占对象的现象，同时也提高了并发性能，但它的缺点：

• 1、乐观锁只能保证一个共享变量的原子性操作，如果多一个或者几个变量，乐观锁就有点力不从心了，但互斥锁能轻易地解决该问题，不管对象数量多少以及对象大小。
• 2、长时间自旋操作可能导致开销较大，加入CAS长时间不成功而一直自旋，就会导致CPU消耗过大。
• 3、ABA问题，CAS的核心思想是比较交换，如果在过程中判断逻辑不够严谨，就会导致在一个线程将数据从A改成B，在另一个线程使用的时候，该线程又将数据改回了A，这样的时候对于另一个线程其实并没有感知到B值的存在。其实在整个过程中这个值是被修改过的。这种情况对于运算依赖比较大的场景影响比较大。解决的思路就是引入版本机制。