synchronized实现机制：
对象锁（monitor）机制 –JDK1.6之前的synchronized（重量级锁）
同步代码块 ：执行同步代码块后首先执行monitorenter指令，退出时执行monitorexit指令。
使用内建锁（synchronized）进行同步，关键在于要获取指定锁对象monitor对象，当线程获取monitor后才能继续向下执行，否则就只能等待。这个获取过程是互斥的，即同一时刻只有一个线程能够获取到对象的monitor监视器。
通常一个monitorenter指令会包含若干个monitorexit指令。
原因在于JVM 需要确保锁在正常执行路径以及异常执行路径上都能够正确的解锁。
同步方法 ：当使用synchronized标记方法时，编译后的字节码中方法的访问标记多了一个ACC_SYNCHRONIZED。该标记表示，进入该方法时，JVM需要进行monitorenter操作，退出该方法时，无论是否正常返回，JVM均需要进行monitorexit操作。
当执行monitorenter时，如果目标对象的monitor计数器为0，表示此对象没有被任何其他对象所持有。
此时，JVM会将该锁对象的持有线程设置为当前线程，并且将计数器+1； 如果目标锁对象的计数器不为0，判断锁对象的持有线程是否是当前线程，如果是，再次将计数器+1（锁的可重入性）。
如果锁对象的持有线程不是当前线程，当前线程需要等待，直至持有线程释放锁。
当执行monitorexit时，JVM会将锁对象的计数器-1，当计数器值减为0时，代表该锁对象已经被释放。
synchronized优化：
悲观锁 （JDK1.6之前的内建锁）：假设每一次执行同步代码块均会产生冲突，所以当线程获取锁成功，会阻塞其他尝试获取该锁的线程。
乐观锁 ：假设所有线程访问共享资源时不会出现冲突，既然不会出现冲突，自然也就不会阻塞其他线程。线程不会出现阻塞状态。
CAS（无锁操作） ，使用CAS叫做比较交换来判断是否出现冲突，出现冲突就重试当前操作，直到不冲突为止。
1.1 CAS操作过程 ： 一般来讲，CAS（V,O,N）： V：内存中地址存放的实际值 O：预期值（旧值） N：更新后的值当执行CAS 后
如果V ==O，，即旧值与内存中实际值相等，表示上次修改该值后没有任何线程再次修改此值，因此可以将N替换到内存中。如果V ！= O，表示内存中的值已经被其他线程做了修改，所以无法将N替换，返回最新的值V（将最新的值取出来）。
当多个线程使用CAS操作同一个变量时，只有一个线程会成功，并成功更新变量值，其余线程均会失败。失败线程会重新尝试，或将线程挂起（阻塞）。
元老级的内建锁（synchronized）最主要的问题：当存在线程竞争的情况下会出现线程阻塞以及唤醒带来的性能问题，对应互斥同步（阻塞同步），效率较低。而CAS并不是武断的将线程挂起，会尝试若干次CAS操作，并非进行耗时的挂起与唤醒操作，因此也叫做非阻塞式同步。
1.2.1 ABA问题 ：
解决思路 ：沿用数据库的乐观锁机制，添加版本号：1A-2B-3AJDK1.5提供的atomic包下的AtomicStampedReference类来解决CAS的ABA问题。
1.2.2 CAS的问题 自旋（CAS）会浪费大量的处理器资源（CPU）与线程阻塞相比，自旋会浪费大量的CPU资源。因为此时线程仍处于运行状态，只不过跑的是无用指令，期望在无用指令时，锁能被释放出来。
解决思路 ： 自适应自旋 ：根据以往自旋等待时能否获取到锁，来动态调整自旋时间（循环尝试数量）如果在上一次自旋时，获取到锁，则此次自旋时间稍微变长一点；如果在上一次自旋结束还没有获取到锁，此次自旋时间稍微短一点。
1.2.3 公平性处于阻塞状态的线程无法立刻竞争被释放的锁，而处于自旋状态的线程很有可能先获取大锁。
内建锁无法实现公平性，lock体系可以实现公平锁。
JDK1.6之后对内建锁做了优化（新增偏向、轻量级锁） 无锁状态 0 01 偏向锁 1 01 轻量级锁 00 重量级锁（JDK1.6之前） 10
这四种状态随着竞争情况逐渐升级，锁可以升级不能降级，为了提高获得锁与释放锁的效率。
2.1 偏向锁 (默认开启)偏向锁是最乐观的锁，从始至终只有一个线程请求一把锁。
偏向锁的获取 ：当一个线程访问同步代码块并获取锁时，会在对象头和栈帧中的锁记录中记录存储偏向锁的线程ID。以后该线程再次进入同步代码块时不再需要CAS来加锁和解锁，只需要简单测试一下对象头的mark word中偏向锁线程ID是否是当前线程ID。 如果成功，表示线程已经获取到锁直接进入代码块运行；
如果测试失败，检查当前偏向锁字段是否为0；
如果为0 ，采用CAS操作将偏向锁字段设置为1，并且更新自己的线程ID 到mark word 字段中。
如果为1，表示此时偏向锁已经被别的线程获取。则此线程不断尝试使用CAS获取偏向锁或者将偏向锁撤销，升级为轻量级锁（升级概率较大）。
偏向锁的撤销 ：偏向锁使用一种等待紧竞争出现才释放锁的机制，当有其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放偏向锁。
小tips：偏向锁的撤销开销较大，需要等待线程进入全局安全点safepoint（当前线程在CPU上没有执行任何有用字节码）
偏向锁从JDK6之后默认开启，但是它在应用程序启动几秒后才默认激活。
2.2 轻量级锁轻量级锁 ：多个线程在不同时间段请求同一把锁，也就是基本不存在锁竞争。针对此种状况，JVM采用轻量级锁来避免线程的阻塞以及唤醒。
加锁 ：线程在执行同步代码块之前，JVM先在当前线程的栈帧中创建用于存储锁记录的空间，并将对象头的mark word 字段直接复制到此空间中。然后线程尝试使用CAS将对象头的 mark word 替换为指向锁记录的指针（指向当前线程）； 如果成功表示获取到轻量级锁。
如果失败，表示其他线程竞争轻量级锁，当前线程便使用自旋来不断尝试。
释放 ：解锁时，会使用CAS将赋值的mark word 替换回对象头，如果成功，表示没有竞争发生，正常解锁。如果失败，表示当前锁存在竞争，进一步膨胀为重量级锁。
重量级锁会阻塞、唤醒请求加锁的线程。
针对的是多个线程同一时刻竞争同一把锁的情况，JVM采用自适应自旋，来避免线程在面对非常小的同步块是，仍会被阻塞以及唤醒。
轻量级锁采用CAS操作，将锁对象的标记字段替换为指向线程的指针，存储着锁对象原本的标记字段。针对的是多个线程在不同时间段申请同一把锁的情况。
偏向锁只会在第一次请求时采用CAS操作，在锁对象的mark- word字段中记录下当前线程ID，伺候运行中持有偏向锁的线程不再有加锁过程。针对的是锁仅会被同一线程持有。
原文链接：https://blog.csdn.net/C_U_N_Z/article/details/95211536
