一、线程安全问题
1、临界资源
多线程编程中，有可能会出现多个线程同时访问同一个共享、可变资源的情况，这个资源我们称之其为临界资源；这种资源可能是：对象、变量、文件等。
- 共享：资源可以由多个线程同时访问
- 可变：资源可以在其生命周期内被修改
2、线程安全问题
当多个线程同时访问一个对象时，如果不用考虑这些线程在运行时环境下的调度和交替执行，也不需要进行额外的同步，或者在调用方进行任何其他的协调操作，调用这个对象的行为都可以获得正确的结果，那就称这个对象是线程安全的，否则就是非线程安全的。
3、如何解决线程安全问题
互斥同步（Mutual Exclusion & Synchronization）是一种最常见也是最主要的并发正确性保障手段。同步是指在多个线程并发访问共享数据时，保证共享数据在同一个时刻只被一条（或者是一些，当使用信号量的时候）线程使用。而互斥是实现同步的一种手段，临界区（Critical Section）、互斥量（Mutex）和信号量（Semaphore）都是常见的互斥实现方式。
在Java里面，最基本的互斥同步手段就是synchronized关键字，另外还有从JDK1.5开始引入了JUC里面的Lock接口，其中用的比较多的就是ReentrantLock，后面也会进行介绍。
二、synchronized使用介绍
synchronized是JVM内置的，是可重入的，其使用方法有三种：加在static修饰的静态方法上，加在普通方法上，同步代码块三种方式。
- 加在静态方法上（public synchronized static void test()），锁的是当前类的Class对象
- 加在实例方法上（public synchronized void test()），锁的是当前对象
- synchronized同步代码块（synchronized(object) {......}），锁的是synchronized后面括号里面的对象
从上面可以看出synchronized锁的其实都是对象。
三、synchronized实现原理
1、synchronized底层指令：monitorenter和monitorexit
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 两条指令分别在同步块逻辑代码的起始位置与结束位置。
|
1
2
3
4
5
6
7
8
|
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指令来保证释放锁
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
|
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 |
2、Object Monitor(监视器锁)机制
上面提到了，只有synchronized锁升级为重量级锁时才会用到Object Monitor(监视器锁)。我们看一下Object Monitor的实现机制是什么？查看OpenJDK源码可以看到Object Monitor由C++语言实现，打开JDK源码目录 “jdk\hotspot\src\share\vm\runtime“可以看到objectMonitor.hpp，这个就是监视器锁的实现，截取一段代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
|
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(锁)。
下节将会介绍一下synchronized的锁优化和锁升级过程
到此这篇关于Java并发编程深入理解之Synchronized的使用及底层原理详解 上的文章就介绍到这了,更多相关Java 并发编程 Synchronized内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://blog.csdn.net/u012988901/article/details/112006772
