如何理解Java Synchronized的使用及底层原理，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
多线程编程中，有可能会出现多个线程同时访问同一个共享、可变资源的情况，这个资源我们称之其为临界资源；这种资源可能是：对象、变量、文件等。
共享：资源可以由多个线程同时访问
可变：资源可以在其生命周期内被修改
当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的，否则就是非线程安全的。
互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，当使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。
在Java里面，最基本的互斥同步手段就是synchronized关键字，另外还有从JDK1.5开始引入了JUC里面的Lock接口，其中用的比较多的就是ReentrantLock，后面也会进行介绍。
synchronized是JVM内置的，是可重入的，其使用方法有三种：加在static修饰的静态方法上，加在普通方法上，同步代码块三种方式。
加在静态方法上（public synchronized static void test()），锁的是当前类的Class对象
加在实例方法上（public synchronized void test()），锁的是当前对象
synchronized同步代码块（synchronized(object) {......}），锁的是synchronized后面括号里面的对象
从上面可以看出synchronized锁的其实都是对象。
synchronized是基于JVM内置锁实现，通过内部对象Object Monitor(监视器锁)实现，基于进入与退出Monitor对象实现方法与代码块同步，监视器锁的实现依赖底层操作系统的Mutex lock（互斥锁）实现，它是一个重量级锁性能较低。当然，JVM内置锁在1.5之后版本做了重大的优化，如锁粗化（Lock Coarsening）、锁消除（Lock Elimination）、轻量级锁（Lightweight Locking）、偏向锁（Biased Locking）、适应性自旋（Adaptive Spinning）等技术来减少锁操作的开销，内置锁的并发性能已经基本与Lock持平。
注意：只有synchronized锁升级为重量级锁时才会用到Object Monitor(监视器锁)。
synchronized关键字被编译成字节码后会被翻译成monitorenter 和monitorexit 两条指令分别在同步块逻辑代码的起始位置与结束位置。
public class TestSynchronized {
private Object obj = new Object();
public void testLock() {
synchronized (obj) {
System.out.println("获取了锁");
}
}
}我们通过javap -c TestSynchronized.class将上面代码的class文件进行反汇编，可以看到如下所示：我们看到了monitorenter 和monitorexit 两条指令，但是monitorexit却出现了两次，原因如下：
第一个monitorexit指令是同步代码块正常释放锁的一个标志；
如果同步代码块中出现Exception或者Error，则会调用第二个monitorexit指令来保证释放锁
public void testLock(); Code: 0: aload_0 1: getfield #3 // Field obj:Ljava/lang/Object; 4: dup 5: astore_1 6: monitorenter 7: getstatic #4 // Field java/lang/System.out:Ljava/io/PrintStream; 10: ldc #5 // String 鑾峰彇浜嗛攣 12: invokevirtual #6 // Method java/io/PrintStream.println:(Ljava/lang/String;)V 15: aload_1 16: monitorexit 17: goto 25 20: astore_2 21: aload_1 22: monitorexit 23: aload_2 24: athrow 25: return Exception table: from to target type 7 17 20 any 20 23 20 any
上面提到了，只有synchronized锁升级为重量级锁时才会用到Object Monitor(监视器锁)。我们看一下Object Monitor的实现机制是什么？查看OpenJDK源码可以看到Object Monitor由C++语言实现，打开JDK源码目录 “jdk\hotspot\src\share\vm\runtime“可以看到objectMonitor.hpp，这个就是监视器锁的实现，截取一段代码如下：
ObjectMonitor() {
_header = NULL; //对象头
_count = 0; //记录加锁次数，锁重入时用到
_waiters = 0, //当前有多少处于wait状态的thread
_recursions = 0; //记录锁的重入次数
_object = NULL;
_owner = 0; //指向持有ObjectMonitor对象的线程
_WaitSet = NULL; //处于wait状态的线程，会被加入到_WaitSet
_WaitSetLock = 0 ;
_Responsible = NULL ;
_succ = NULL ;
_cxq = NULL ;
FreeNext = NULL ;
_EntryList = NULL ;//处于等待加锁block状态的线程，会被加入到该列表
_SpinFreq = 0 ;
_SpinClock = 0 ;
OwnerIsThread = 0 ;
_previous_owner_tid = 0;
}其中几个比较重要的字段：
_header 对象头，前面说过synchronized锁升级为重量级锁之后才会用到objectMonitor，这时候对象头的Mark word会有一个指向重量级锁Monitor的指针
_count 线程获取锁的次数，每加锁一次该值加1。
_waiters 当前有多少处于wait状态的thread
_recursions 锁的重入次数
_owner 指向持有ObjectMonitor对象的线程地址。
_WaitSet 存放调用wait方法，而进入等待状态的线程的队列。
_EntryList 处于等待加锁block状态的线程，会被加入到该列表
ObjectMonitor的加锁解锁过程如下图所示，ObjectMonitor中有两个队列，_WaitSet 和 _EntryList，用来保存ObjectWaiter对象列表(每个等待锁的线程都会被封装成ObjectWaiter对象)；整个monitor运行的机制过程如下：
_owner指向持有ObjectMonitor对象的线程，当多个线程同时访问一段同步代码时，首先会进入 _EntryList 集合
当线程获取到对象的monitor 后进入 _Owner 区域并把monitor中的owner变量设置为当前线程的同时，monitor中的计数器count加1，
若已经获取锁的线程调用 wait() 方法，将释放当前持有的monitor，owner变量恢复为null，count自减1，同时该线程进入 WaitSet集合中等待被唤醒。
若当前线程执行完毕也将释放monitor(锁)并复位变量的值，以便其他线程进入获取monitor(锁)。
关于如何理解Java Synchronized的使用及底层原理问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注亿速云行业资讯频道了解更多相关知识。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
