Synchronized一道墙

大家好，上次阿清的文章，提到了并发问题的三大根源，为了保证并发编程的一致性，Java提供了一个synchronized关键字来保证并发的正确执行。

synchronized能避免并发的三个问题，即操作原子性、缓存可见一致性、指令重排序这三个并发问题。它能保证多线程的安全。

—

synchronized加锁的方式

分为显式加锁与隐式加锁两种。

举两个🌰：

synchronized加锁的两种方法

（1）显式加锁：

public class Test {
    
     public  void  codeLock(){
         //显示加锁，锁的是当前Test实例对象
         synchronized(this){
             //Todo
         }
     }
    
     Object objA=new Object();
     public  void  objLock(){
         //显示加锁，锁的是objA对象
         synchronized(objA){
             //Todo
         }
     }
 }

（2）隐式加锁：

public class Test {
     //修饰在对象方法上，隐式加锁，效果等于synchronized(this)，即Test的实例对象
     public synchronized void  thisLock(){
 
     }
}

public class Test {
     //修饰在类方法上，隐式加锁,效果等于synchronized(Test.class)
     public static synchronized void  classLock(){
     
     }
}

注意：Test.class 与 Test的实例对象在Java堆中是两个不一样的对象。

因此，若在同一个类中，分别为 xx.class对象或 xx的实例对象加锁后，此时也许会导致并发出现错误。

大家看下面这段代码：

public class Test {
     // 静态变量 count
     static Integer count;
     
     //线程A执行此方法
     public synchronized void thisLock(){
         count++;
     }
     
     //线程B执行此方法
     public static synchronized void classLock(){
         count++;
     }
 
 }

此时，在多线程的情况下，count的数值便会发生错误，因为在获得Test.class对象锁与 Test的实例对象锁之后，都能够操作count变量。

—

synchronized的底层原理

synchronized的底层使用monitor进行加锁与解锁：

monitorenter进行加锁，monitorexit进行解锁。

加锁过程：

使用monitorenter进行锁的竞争。
获得锁后，访问共享资源，若获得锁失败，则进入等待队列。
分两种情况：

若线程执行条件不成立，则进入wait状态，并释放锁，该线程进入等待队列，选择notify 或 notifyAll 唤醒等待队列中的其他线程。
若条件成立，则正常执行，使用monitorexit退出临界区。

使用notify 、或notifyAll唤醒其他的线程

—

synchronized锁升级过程

锁升级过程：

无锁状态：此时不存在锁的竞争，无需加锁。
偏向锁状态：经常只有一个线程来加锁。避免加锁的开销，并不会真正的加锁，过程如下：
轻量级锁状态：有线程来参与锁的竞争，但是锁竞争的时间很短。

若申请锁不成功，通过自旋继续获取这个锁，超过一定时间后，则进行升级成重量级锁。
重量级锁状态：有大量的线程参与锁的竞争，冲突性很高。

若尝试获取不到锁，线程则进入队列等待，等待前面获取锁的线程释放了锁之后再开启下一轮的锁竞争，这就是重量级锁，只有当锁升级为重量级锁的时候才真正意义上的在操作系统层面进行了加锁操作。