目录
静态synchronized方法 与 静态synchronized(class)代码块
一、synchronized的使用
synchronized方法：
语义：
- 如果A线程调用了某个实例对象的某个synchronized方法M，则A线程就获得了这个实例对象的锁，在A线程调用M方法结束之前(即A线程释放该实例对象的锁之前)，其它线程不能调用该实例对象的任何synchronized方法和任何synchronized(this)同步代码块，因为其它线程无法获取到该实例对象的锁。
说明：
- 哪个线程先执行带synchronized关键字的方法，哪个线程就持有该方法所属对象的锁。
- synchronized方法获取的锁是对象锁，故线程锁的是对象。
- synchronized锁重入
- 当A线程得到一个对象锁后，再次请求该对象锁时，是可以再次得到该对象的锁。
- 在一个synchronized方法/块的内部调用本类的其它synchronized方法/块时，是永远可以得到锁的。
- 当一个线程得到一个对象锁后，这个线程也可以调用该对象从父类继承过来的synchronized方法。
- 出现异常，锁自动释放：当一个线程执行的代码出现异常时，该线程持有的锁会自动释放。
synchronized语句块：
this对象作为锁的同步代码块：即synchronized(this)
- 说明：当一个线程访问一个对象的某个synchronized(this)同步代码块时，其它线程对该对象的synchronized方法和synchronized(this)同步代码块的访问将被阻塞。
非this对象作为锁的同步代码块：即synchronized(非this对象)
- 优点：一个对象中的synchronized(非this对象)同步代码块不会与该对象中的synchronized方法争抢this锁，二者间的调用时异步的。
- 说明：当一个线程访问一个对象的某个synchronized(非this对象)同步代码块时，其它线程可以访问该对象的synchronized方法，因为二者锁定的对象不同。
- 注意：当一个线程访问一个对象O的某个synchronized(非this对象X)同步代码块时，其它线程不可以访问X对象中的synchronized方法和synchronized(this)同步代码块，但是可以访问O对象中的synchronized方法或synchronized(this)代码块。
静态synchronized方法 与 静态synchronized(class)代码块
- 持有的锁是类的Class锁。
- 调用前必须先获取到所属的类的Class锁。
- 静态synchronized方法和非静态synchronized方法持有的是不同的锁：静态synchronized方法持有的是Class锁，非静态synchronized方法持有的是对象锁，静态同步代码块与非静态同步代码块也是如此。
- Class锁可以对类的所有对象实例起作用，换句话说：如果一个线程通过该类的某个对象实例已经获取到了该类的Class锁，则其它线程无法通过另外的对象实例来获取到该类的Class锁。
二、synchronized的实现
synchronized是基于进入monitor对象和退出monitor对象来实现的，无论是显式同步还是隐式同步。
synchronized语句块的实现：
- 使用javap -c 类名)将class文件反编译后可以看到：同步块的入口位置和出口位置(方法结束处和异常处)分别插入了monitorenter字节码指令和monitorexit字节码指令，故同步代码块属于显示同步。
- 线程执行到monitorenter指令时，尝试获取对象的锁，执行monitorexit指令时会释放对象的锁。
synchronized方法的实现：
- JVM从Class文件中的方法结构(method_info)中的 ACC_SYNCHRONIZED 访问标志区分一个方法是否为同步方法，故同步方法属于隐式同步。
- 当方法调用时，调用指令会检查方法的ACC_SYNCHRONIZED访问标志是否被设置，如果设置了，执行线程将先持有monitor，然后再执行方法，最后在方法完成时释放monitor。
- 在方法执行期间，其它线程无法获取该monitor。
- 如果一个同步方法执行期间抛出了异常，并且在方法内部无法处理此异常，那这个同步方法所持有的monitor将在异常抛到同步方法之外时自动释放。
method_info 结构格式如下(java虚拟机规范中的摘录)
method_info {
u2 access_flags; // 用于定义当前方法的访问权限和基本属性的标志
u2 name_index;
u2 descriptor_index;
u2 attributes_count;
attribute_info attributes[attributes_count];
}
method_info结构中访问标记(access_flags)的取值：
标记名 值 说明
ACC_PUBLIC 0x0001 public，方法可以从包外访问
ACC_PRIVATE 0x0002 private，方法只能本类中访问
ACC_PROTECTED 0x0004 protected，方法在自身和子类可以访问
ACC_STATIC 0x0008 static，静态方法
ACC_FINAL 0x0010 final，方法不能被重写
ACC_SYNCHRONIZED 0x0020 synchronized，方法由monitor同步
...
获取锁和释放锁的内存原语：
线程获取锁：
- JMM会把该线程对应的本地内存置为无效。从而使得被monitor保护的临界区代码必须从主内存中读取共享变量。
线程释放锁：
- JMM会把该线程对应的本地内存中的共享变量刷新到主内存中，即：
- 将本地内存中的数据设置为无效，
- 从主内存中将数据复制到本地内存中，
- 在本地内存中进行操作，
- 操作完成后将本地内存中的数据刷新到主内存中。整体看起来就像是直接在主内存中操作一样。
synchronized的可重入性：
- 当一个线程再次请求自己持有对象锁的临界资源时，这种情况属于重入锁，请求将会成功。
- 由于synchronized是基于monitor实现的，故每次重入，monitor中的计数器仍会加1。
深入理解monitor：
从java的视角看synchronized
- synchronized使用的锁对象(monitor)存储在java对象头中。
- monitor对象：
- 每个java对象都拥有一个Monitor锁(别问我为什么，虚拟机就是这样设计的)。
- 当一个monitor被持有后，它将处于锁定状态。
- monitor对象：
- java对象的内存布局
从C++源码(虚拟机的实现)看synchronized：
- 参考：https://www.cnblogs.com/dennyzhangdd/p/6734638.html
oopDesc ---> markOopDesc monitor()方法 --> ObjectMonitor 即 monitor -> monitor enter、monitor exit 1)openjdk\hotspot\src\share\vm\oops\oop.hpp下的oopDesc类是JVM对象的顶级基类，故每个object都包含markOop。 class oopDesc { friend class VMStructs; private: volatile markOop _mark; //标记字段(Mark Word) union _metadata { Klass* _klass; //对象类型元数据的指针 narrowKlass _compressed_klass; } _metadata; // Fast access to barrier set. Must be initialized. static BarrierSet* _bs; public: markOop mark() const { return _mark; } markOop* mark_addr() const { return (markOop*) &_mark; } void set_mark(volatile markOop m) { _mark = m; } void release_set_mark(markOop m); markOop cas_set_mark(markOop new_mark, markOop old_mark); // Used only to re-initialize the mark word (e.g., of promoted // objects during a GC) -- requires a valid klass pointer void init_mark(); Klass* klass() const; Klass* klass_or_null() const volatile; Klass** klass_addr(); narrowKlass* compressed_klass_addr(); ....省略... } 2)markOopDesc继承自oopDesc，并拓展了自己的方法monitor()，该方法返回一个ObjectMonitor*对象指针。 ObjectMonitor* monitor() const { assert(has_monitor(), "check"); // Use xor instead of &~ to provide one extra tag-bit check. return (ObjectMonitor*) (value() ^ monitor_value); // -------------- 补充 --------------------- // value()的实现： uintptr_t value() const { return (uintptr_t) this; } // // monitor_value的实现： // enum { // locked_value = 0,//00偏向锁 // unlocked_value = 1,//01无锁 // monitor_value = 2,//10监视器锁，又叫重量级锁 // marked_value = 3,//11GC标记 // biased_lock_pattern = 5 //101偏向锁 // }; // -------------- 补充 --------------------- } 3)在HotSpot虚拟机中，采用ObjectMonitor类来实现monitor。 openjdk\hotspot\src\share\vm\runtime\objectMonitor.hpp源码如下： ObjectMonitor() { _header = NULL;//markOop对象头 _count = 0; _waiters = 0,//等待线程数 _recursions = 0;//重入次数 _object = NULL; _owner = NULL;//指向获得ObjectMonitor对象的线程或基础锁 _WaitSet = NULL;//处于wait状态的线程，会被加入到wait set； _WaitSetLock = 0 ; _Responsible = NULL ; _succ = NULL ; _cxq = NULL ; FreeNext = NULL ; _EntryList = NULL ;//处于等待锁block状态的线程，会被加入到entry set； _SpinFreq = 0 ; _SpinClock = 0 ; OwnerIsThread = 0 ;// _owner is (Thread *) vs SP/BasicLock _previous_owner_tid = 0;// 监视器前一个拥有者线程的ID }
三、JVM对synchronized的优化
锁消除、锁粗化
使用偏向锁和轻量级锁
- java6为了减少获取锁和释放锁带来的性能消耗，引入了偏向锁和轻量级锁。
- 锁一共有4种状态，级别从低到高依次是：无锁状态、偏向锁、轻量级锁、重量级锁。
- 锁的状态会随着竞争情况逐渐升级，并且只可以升级而不能降级。
偏向锁
背景：
- 大多数情况下，锁不仅不存在多线程竞争，而且总是由同一线程多次获得，为了让线程获得锁的代价更低而引入了偏向锁。
原理：
- 当一个线程访问同步块并获取锁时，会在对象头和栈帧中的锁记录里存储锁偏向的线程ID。
- 以后该线程在进入和退出同步块时就不需要进行CAS操作来加锁和解锁，只需简单地判断一下对象头的Mark Word里是否存储着指向当前线程的偏向锁。
目的：
- 偏向锁实际上是一种优化锁，其目的是为了减少数据在无竞争情况下的性能损耗。
偏向锁的获取：
- 访问Mark Word中偏向锁的标识位是否为1，如果是1，则确定为偏向锁。
- 如果是偏向锁，则判断Mark Word中的偏向线程ID是否指向当前线程：
- 若偏向线程ID指向当前线程，则表明当前线程已经获取到了锁；
- 若偏向线程ID并未指向当前线程，则通过CAS操作尝试获取偏向锁，如果获取锁成功，则将Mark Word中的偏向线程ID设置为当前线程ID；
- 如果偏向锁的标识位为0，说明此时是处于无锁状态，则当前线程通过CAS操作尝试获取偏向锁，如果获取锁成功，则将Mark Word中的偏向线程ID设置为当前线程ID；并且将偏向标识位设为1。
偏向锁的释放：
- 释放的时机：
- 当其它的线程尝试获取偏向锁时，持有偏向锁的线程才会释放偏向锁。
- 释放的过程：
- 等待到达全局安全点时(在这个时间点上没有正在执行的字节码)，获得偏向锁的线程被挂起，然后检查持有偏向锁的线程是否活着，如果线程不处于活动状态，则将对象头设置成无锁状态。
- 如果线程还活着，说明此时发生了竞争，则偏向锁升级为轻量级锁，然后刚刚被暂停的线程会继续往下执行同步代码。
优缺点：
- 加锁和解锁不需要额外的消耗，和执行非同步方法相比仅存在纳秒级的差距
- 如果线程间存在锁竞争，偏向锁的释放会带来额外的消耗。
说明：
- 偏向锁默认在应用程序启动几秒钟之后才激活。
- 可以通过设置 -XX:BiasedLockingStartupDelay=0 来关闭延迟。
- 可以通过设置 -XX:-UseBiasedLocking=false 来关闭偏向锁，程序默认会进入轻量级锁状态。(如果应用程序里的锁大多情况下处于竞争状态，则应该将偏向锁关闭)
轻量级锁
原理：
- 当使用轻量级锁(锁标识位为00)时，线程在执行同步块之前，JVM会先在当前线程的栈桢中创建用于存储锁记录的空间，并将对象头中的Mark Word复制到锁记录中(注:锁记录中的标识字段称为Displaced Mark Word)。
- 将对象头中的MarkWord复制到栈桢中的锁记录中之后，虚拟机将尝试使用CAS将对象头中Mark Word替换为指向该线程虚拟机栈中锁记录的指针，此时如果没有线程占有锁或者没有线程竞争锁，则当前线程成功获取到锁，然后执行同步块中的代码。
- 如果在获取到锁的线程执行同步代码的过程中，另一个线程也完成了栈桢中锁记录的创建，并且已经将对象头中的MarkWord复制到了自己的锁记录中，然后尝试使用CAS将对象头中的MarkWord修改为指向自己的锁记录的指针，但是由于之前获取到锁的线程已经将对象头中的MarkWord修改过了(并且现在还在执行同步体中的代码,即仍然持有着锁)，所以此时对象头中的MarkWord与当前线程锁记录中MarkWord的值不同，导致CAS操作失败，然后该线程就会不停地循环使用CAS操作试图将对象头中的MarkWord替换为自己锁记录中MarkWord的值，(当循环次数或循环时间达到上限时停止循环)如果在循环结束之前CAS操作成功，那么该线程就可以成功获取到锁，如果循环结束之后依然获取不到锁，则锁获取失败，对象头中的MarkWord会被修改为指向重量级锁的指针，然后这个获取锁失败的线程就会被挂起，阻塞了。
- 当持有锁的那个线程执行完同步体之后，使用CAS操作将对象头中的MarkWord还原为最初的状态时(将对象头中指向锁记录的指针替换为Displaced Mark Word )，发现MarkWord已被修改为指向重量级锁的指针，因此CAS操作失败，该线程会释放锁并唤起阻塞等待的线程，开始新一轮夺锁之争，而此时，轻量级锁已经膨胀为重量级锁，所有竞争失败的线程都会阻塞，而不是自旋。
自旋锁：
概念：
- 所谓自旋锁，就是让没有获得锁的进程自己运行一段时间自循环(默认开启)，但是不挂起线程，在没有多线程竞争的前提下，减少传统的重量级锁带来的性能损耗。
说明：
- 自旋的代价就是该线程会一直占用处理器如果锁占用的时间很短，自旋等待的效果很好，反之，自旋锁会消耗大量处理器资源。
- 因此，自旋的等待时间必须有一定限度，超过限度还没有获得锁，就要挂起线程。
重量级锁
概念：
- java6之前的synchronized属于重量级锁，效率低下，因为monitor是依赖操作系统的Mutex Lock(互斥量)来实现的。
- 多线程竞争锁时，会引起线程的上下文切换(即在cpu分配的时间片还没有用完的情况下进行了上下文切换)。
- 操作系统实现线程的上下文切换需要从用户态转换到核心态，这个状态之间的转换需要相对较长的时间，时间成本相对较高。
- 在互斥状态下，没有得到锁的线程会被挂起阻塞，而挂起线程和恢复线程的操作都需要从用户态转入内核态中完成。
优点：
- 线程竞争不使用自旋，不会消耗cpu。
缺点：
- 线程阻塞，响应时间缓
4813
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
