一、简介
synchronized可以保证在同一时刻，只有一个线程可以执行某个方法或某个代码块,synchronized把锁信息存放在对象头的MarkWord中。
synchronized作用在非静态方法上是对方法的加锁，synchronized作用在静态方法上是对当前的类加锁。
在早期的jdk版本中，synchronized是一个重量级锁，保证线程的安全但是效率很低。后来对synchronized进行了优化，有了一个锁升级的过程：
无锁态（new）-->偏向锁-->轻量级锁（自旋锁）-->重量级锁
通过MarkWord中的8个字节也就是64位来记录锁信息。
二、实现原理
在java代码中使用synchronized可是使用在代码块和方法中，根据synchronized用的位置可以有如下表所示这些使用场景：
如表所示synchronized可以用在方法上也可以使用在代码块中，方法是实例方法和静态方法分别锁的是该类的实例对象和该类的对象。而使用在代码块中根据锁的目标对象
也可以分为三种，具体的可以看表数据。这里的需要注意的是如果锁的是类对象的话，尽管new多个实例对象，依然会被锁住。
2.1、对象锁（monitor）机制
现在来进一步分析synchronized的具体底层实现，有如下一个简单的示例代码：
public class SynchronizedDemo {
public static void main(String[] args) {
synchronized (SynchronizedDemo.class) {
System.out.println("hello synchronized！");
}
}
}
上述代码通过synchronized“锁住”当前类对象来进行同步，将java代码进行编译之后通过javap -v SynchronizedDemo .class来查看对应的main方法字节码如下：
public static void main(java.lang.String[]);
descriptor: ([Ljava/lang/String;)V
flags: ACC_PUBLIC, ACC_STATIC
Code:
stack=2, locals=3, args_size=1
0: ldc #2 // class com/codercc/chapter3/SynchronizedDemo
2: dup
3: astore_1
4: **monitorenter**
5: getstatic #3 // Field java/lang/System.out:Ljava/io/PrintStream;
8: ldc #4 // String hello synchronized！
10: invokevirtual #5 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
13: aload_1
14: monitorexit
15: **goto** 23
18: astore_2
19: aload_1
20: **monitorexit**
21: aload_2
22: **athrow**
23: **return
从线程状态变化的角度来看，如果要想进入到同步块或者执行同步方法，都需要先获取到对象的monitor，如果获取不到则会变更为BLOCKED状态，具体过程如下图所示：
从上图可以看出任意线程对Object的访问，首先要获得Object的monitor，如果获取失败，该线程就会进入到同步队列中，线程状态变为BLOCKED。当monitor持有者释放后，在同步队列中的线程才会有机会重新获取monitor，才能继续执行。
2.2、synchronized的happens-before关系
happens-before规则，其中有一条就是监视器锁规则：对同一个监视器的解锁happens-before于对该监视器的加锁。为了进一步了解synchronized的并发语义，通过示例代码分析这条happens-before规则，示例代码如下：
public class MonitorDemo {
private int a = 0;
public synchronized void writer() { // 1
a++; // 2
} // 3
public synchronized void reader() { // 4
int i = a; // 5
} // 6
}
在并发时，第5步操作中读取到的变量a的值是多少呢？这就需要通过happens-before规则来进行分析，示例代码的happens-before关系如下图所示：
上图中每一个箭头连接的两个节点就代表之间的happens-before关系，黑色的是通过程序顺序规则推导出来，通过监视器锁规则可以推导出线程A释放锁happens-before线程B加锁，即红色线表示。蓝色的线则是通过传递性规则进一步推导的happens-before关系。最终得到的结论就是操作2 happens-before 5，通过这个关系可以得出什么？
根据happens-before的定义中的一条：如果A happens-before B，则A的执行结果对B可见。那么在该示例代码中，线程A先对共享变量A进行加1，由2 happens-before 5关系可知线程A的执行结果对线程B可见即线程B所读取到的a的值为1
2.3、锁获取和锁释放的内存语义
JMM核心为两个部分：happens-before规则以及内存抽象模型。在分析完synchronized的happens-before关系后还是不太完整的，接下来看看基于java内存抽象模型的synchronized的内存语义，具体过程如下图所示：
针对线程A的操作而言，从上图可以看出线程A会首先先从主内存中读取共享变量a=0的值然后将该变量拷贝到线程本地内存。然后基于该值进行数据操作后变量a变为1，然后会将值写入到主内存中。
对线程B而言执行流程如上图所示。线程B获取锁的时候会强制从主内存中共享变量a的值，而此时变量a已经是最新值了。接下来线程B会将该值拷贝到工作内存中进行操作，同样的执行完操作后也会重新写入到主内存中。
从横向来看，线程A和线程线程都是基于主内存中的共享变量互相感知到对方的数据操作，并基于共享变量来完成并发实体中的协同工作，整个过程就好像线程A给线程B发送了一个数据变更的“通知”，这种通信机制就是基于共享内存的并发模型结构导致。
三、synchronized优化
通过上面的讨论对synchronized应该有一定了解，它最大的特征就是在同一时刻只有一个线程能够获得对象monitor，从而确保当前线程能够执行到相应的同步逻辑，对线程之间而言表现为互斥性（排它性） 。自然而然这种同步方式会有效率相对低下的弊端，既然同步流程不能发生改变，那么能不能让每次获取锁的速度更快或者降低阻塞等待的概率呢？也就是通过局部的优化来提升系统整体的并发同步的效率。比如去收银台付款的场景，之前的方式是大家都去排队，然后去纸币付款收银员找零。甚至有的时候付款的时候还需要在包里拿出钱包拿出钱，这个过程是比较耗时的。针对付款的流程，就可以通过线上化的手段来进行优化，在现在只需要通过支付宝扫描二维码就可以完成付款了，也省去了收银员找零的时间。尽管整个付款场景还是需要排队，但是因为付款（类似于获取锁释放锁）这个环节的优化导致耗时大大缩短，对收银台（系统整体并发效率）而言操作效率就极大的带来提升。如此类比，如果能对锁操作过程进行优化的话，也会对并发效率带来极大的提升。
3.1、CAS操作
3.1.1、什么是CAS
使用锁时，线程获取锁是一种悲观锁策略，即假设每一次执行临界区代码都会产生冲突，所以当前线程获取到锁的时候同时也会阻塞其他线程获取该锁。而CAS操作（又称为无锁操作）是一种乐观锁策略，它假设所有线程访问共享资源的时候不会出现冲突，既然不会出现冲突自然而然就不会阻塞其他线程的操作。因此，线程就不会出现阻塞停顿的状态。那么，如果出现冲突了怎么办？无锁操作是使用CAS(compare and swap)又叫做比较交换来鉴别线程是否出现冲突，出现冲突就重试当前操作直到没有冲突为止。
3.1.2、CAS的操作过程
CAS比较交换的过程可以通俗的理解为CAS(V,O,N)，包含三个值分别为：V 内存地址存放的实际值；O 预期的值（旧值）；N 更新的新值。当V和O相同时，也就是说旧值和内存中实际的值相同表明该值没有被其他线程更改过，即该旧值O就是目前来说最新的值了，自然而然可以将新值N赋值给V。反之，V和O不相同，表明该值已经被其他线程改过了则该旧值O不是最新版本的值了，所以不能将新值N赋给V，返回V即可。当多个线程使用CAS操作一个变量是，只有一个线程会成功，并成功更新，其余会失败。失败的线程会重新尝试，当然也可以选择挂起线程。
CAS的实现需要硬件指令集的支撑，在JDK1.5后虚拟机才可以使用处理器提供的CMPXCHG指令实现。
Synchronized VS CAS
元老级的Synchronized(未优化前)最主要的问题是：在存在线程竞争的情况下会出现线程阻塞和唤醒锁带来的性能问题，因为这是一种互斥同步（阻塞同步）。而CAS并不是武断的间线程挂起，当CAS操作失败后会进行一定的尝试，而非进行耗时的挂起唤醒的操作，因此也叫做非阻塞同步。这是两者主要的区别。
3.1.3、CAS的应用场景
在J.U.C包中利用CAS实现类有很多，可以说是支撑起整个concurrency包的实现，在Lock实现中会有CAS改变state变量，在atomic包中的实现类也几乎都是用CAS实现，关于这些具体的实现场景在之后会详细聊聊，现在有个印象。
3.1.4、CAS的问题
1、ABA问题
因为CAS会检查旧值有没有变化，这里存在这样一个有意思的问题。比如一个旧值A变为了成B，然后再变成A，刚好在做CAS时检查发现旧值并没有变化依然为A，但是实际上的确发生了变化。解决方案可以沿袭数据库中常用的乐观锁方式，添加一个版本号可以解决。原来的变化路径A->B->A就变成了1A->2B->3C。在java 1.5后的atomic包中提供了AtomicStampedReference来解决ABA问题，解决思路就是这样的。
2、自旋时间过长
使用CAS时非阻塞同步，也就是说不会将线程挂起，会自旋（无非就是一个死循环）进行下一次尝试，如果这里自旋时间过长对性能是很大的消耗。如果JVM能支持处理器提供的pause指令，那么在效率上会有一定的提升
3、只能保证一个共享变量的原子操作
当对一个共享变量执行操作时CAS能保证其原子性，如果对多个共享变量进行操作,CAS就不能保证其原子性。有一个解决方案是利用对象整合多个共享变量，即一个类中的成员变量就是这几个共享变量。然后将这个对象做CAS操作就可以保证其原子性。atomic中提供了AtomicReference来保证引用对象之间的原子性。
3.2、Java对象头
在同步的时候是获取对象的monitor,即获取到对象的锁。那么对象的锁怎么理解？无非就是类似对对象的一个标志，那么这个标志就是存放在Java对象的对象头。Java对象头里的Mark Word里默认的存放的对象的Hashcode,分代年龄和锁标记位。32为JVM Mark Word默认存储结构为（注:java对象头以及下面的锁状态变化摘自《java并发编程的艺术》一书。
如图在Mark Word会默认存放hasdcode，年龄值以及锁标志位等信息。
Java SE 1.6中，锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁状态、轻量级锁状态和重量级锁状态，这几个状态会随着竞争情况逐渐升级。锁可以升级但不能降级，意味着偏向锁升级成轻量级锁后不能降级成偏向锁。这种锁升级却不能降级的策略，目的是为了提高获得锁和释放锁的效率。对象的MarkWord变化为下图：
3.3、偏向锁
HotSpot的作者经过研究发现，大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。
偏向锁的获取
当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID，以后该线程在进入和退出同步块时不需要进行CAS操作来加锁和解锁，只需简单地测试一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。如果测试成功，表示线程已经获得了锁。如果测试失败，则需要再测试一下Mark Word中偏向锁的标识是否设置成1（表示当前是偏向锁）：如果没有设置，则使用CAS竞争锁；如果设置了，则尝试使用CAS将对象头的偏向锁指向当前线程
偏向锁的撤销
偏向锁使用了一种等到竞争出现才释放锁的机制，所以当其他线程尝试竞争偏向锁时，持有偏向锁的线程才会释放锁。
如图，偏向锁的撤销，需要等待全局安全点（在这个时间点上没有正在执行的字节码）。它会首先暂停拥有偏向锁的线程，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态；如果线程仍然活着，拥有偏向锁的栈会被执行，遍历偏向对象的锁记录，栈中的锁记录和对象头的Mark Word要么重新偏向于其他线程，要么恢复到无锁或者标记对象不适合作为偏向锁，最后唤醒暂停的线程。
下图线程1展示了偏向锁获取的过程，线程2展示了偏向锁撤销的过程。
如何关闭偏向锁
偏向锁在Java 6和Java 7里是默认启用的，但是它在应用程序启动几秒钟之后才激活，如有必要可以使用JVM参数来关闭延迟：-XX:BiasedLockingStartupDelay=0。如果你确定应用程序里所有的锁通常情况下处于竞争状态，可以通过JVM参数关闭偏向锁：-XX:-UseBiasedLocking=false，那么程序默认会进入轻量级锁状态
3.4、轻量级锁
加锁
线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中，官方称为Displaced Mark Word。然后线程尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针。如果成功，当前线程获得锁，如果失败，表示其他线程竞争锁，当前线程便尝试使用自旋来获取锁。
解锁
轻量级解锁时，会使用原子的CAS操作将Displaced Mark Word替换回到对象头，如果成功，则表示没有竞争发生。如果失败，表示当前锁存在竞争，锁就会膨胀成重量级锁。下图是两个线程同时争夺锁，导致锁膨胀的流程图。
因为自旋会消耗CPU，为了避免无用的自旋（比如获得锁的线程被阻塞住了），一旦锁升级成重量级锁，就不会再恢复到轻量级锁状态。当锁处于这个状态下，其他线程试图获取锁时，都会被阻塞住，当持有锁的线程释放锁之后会唤醒这些线程，被唤醒的线程就会进行新一轮的夺锁之争。
3.5、各种锁比较
四、synchronized的使用
synchronized可以用在实例方法和静态方法上，是隐式使用。
synchronized可以用在代码块上，是显式使用。
synchronized锁是可重入锁、独享锁、悲观锁。
示例：
public class SynchronizedDemo {
public static void main(String[] args) {
final Counter counter1 = new Counter();
final Counter counter2 = new Counter();
new Thread(new Runnable() {
public void run() {
counter1.add();
// Counter.staticAdd();
}
}).start();
new Thread(new Runnable() {
public void run() {
counter2.add();
// Counter.staticAdd();
}
}).start();
}
}
class Counter {
public static volatile int a;
//用在实例方法上，是synchronized(this)
public synchronized void add() {
System.out.println("线程：" + Thread.currentThread().getName());
a++;
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
//用在静态方法上，是synchronized(Counter.class)
public synchronized static void staticAdd() {
System.out.println("线程：" + Thread.currentThread().getName());
a++;
LockSupport.parkNanos(1000 * 1000 * 1000 * 2);
}
public void demo() {
//用在代码块上
synchronized (this) {
a++;
}
}
}
上面的例子，当synchronized用在实例方法上，其实就是对this加锁，也就是实例化的对象，当实例化多个对象时，其实就是加了多个锁，当在多个线程多个实例调用的时候，不会出现阻塞；synchronized用在静态方法上，其实就是对类对象进行加锁。
public class SynchronizedDemo02 implements Runnable {
private static int count = 0;
public static void main(String[] args) {
for (int i = 0; i < 10; i++) {
Thread thread = new Thread(new SynchronizedDemo02());
thread.start();
}
try {
Thread.sleep(500);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("result: " + count);
}
public void run() {
synchronized (SynchronizedDemo.class) {
for (int i = 0; i < 1000000; i++)
count++;
}
}
}
五、锁升级过程详解
当给一个对象增加synchronized锁之后，相当于上了一个偏向锁。
当有一个线程去请求时，就把这个对象MarkWord的ID改为当前线程指针ID（JavaThread），只允许这一个线程去请求对象。
当有其他线程也去请求时，就把锁升级为轻量级锁。每个线程在自己的线程栈中生成LockRecord，用CAS自旋操作将请求对象MarkWordID改为自己的LockRecord，成功的线程请求到了该对象，未成功的对象继续自旋。
如果竞争加剧，当有线程自旋超过一定次数时（在JDK1.6之后，这个自旋次数由JVM自己控制），就将轻量级锁升级为重量级锁，线程挂起，进入等待队列，等待操作系统的调度。
加锁的字节码实现
synchronized关键字被编译成字节码之后会被翻译成monitorenter和monitorexit两条指令，进入同步代码块时执行monitorenter，同步代码块执行完毕后执行monitorexit。
六、锁消除
在某些情况下，如果JVM认为不需要锁，会自动消除锁，比如下面这段代码：
public void add(String a,String b){
StringBuffer sb=new StringBuffer();
sb.append(a).append(b);
}
StringBuffer是线程安全的，但是在这个add方法中stringbuffer是不能共享的资源，因此加锁只会徒增性能消耗，JVM就会消除StringBuffer内部的锁。
七、锁粗化
在某些情况下，JVM检测到一连串的操作都在对同一个对象不断加锁，就会将这个锁加到这一连串操作的外部，比如：
StringBuffer sb=new StringBuffer();
while(i<100){
sb.append(str);
i++;
}
上述操作StringBuffer每次添加数据都要加锁和解锁，连续100次，这时候JVM就会将锁加到更外层（while）部分。
评论