synchronized是Java中的一个关键字,通常用于多线程环境下,在同一时刻只允许有一个线程访问共享变量。它会根据情况,将锁升级为不同状态,如偏向锁(可以关掉),轻量级锁(无锁/自旋锁/自适应锁),重量级锁。重量级锁会调用操作系统层面的minotor,这时候获得不到线程的对象会被阻塞在队列中。这也是经常被称为一个重量级锁原因。
另外它可以保证原子性,可见性和有序性。支持可重入,但不可中断(Lock的tryLock方法是可以被中断的)。
内部锁底层实现:
- 进入时,执行monitorenter,将计数器+1,释放锁monitorexit时,计数器-1
- 当一个线程判断到计数器为0时,则当前锁空闲,可以占用;反之,当前线程进入等待状态
https://www.zhihu.com/question/57794716/answer/606126905
package synchronizedTest;
public class SynchronizedTest {
// 作用于方法上(或者静态方法上)
public synchronized void test(){
System.out.println("synchronized test!!!");
}
// 作用于代码块内
public void testBlock(){
synchronized (this) {
System.out.println("synchronized test!!!");
}
}
}
//作用于一个类上
class ClassName {
public void method() {
synchronized(ClassName.class) {
// todo
}
}
}
synchronized 内部字节码指令可以保证出现异常时正常解锁。
static final Object lock = new Object();
static int counter = 0;
public static void main(String[] args) {
synchronized (lock) {
counter++;
}
}
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: getstatic #2 // <- lock引用 (synchronized开始)
3: dup
4: astore_1 // lock引用 -> slot 1 <解锁时候用>
5: monitorenter // 将 lock对象 MarkWord 置为 Monitor 指针
6: getstatic #3 // <- i
9: iconst_1 // 准备常数 1
10: iadd // +1
11: putstatic #3 // -> i
14: aload_1 // <- lock引用 <解锁>
15: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
16: goto 24
//19-23: Exception table还在检测范围内检测异常,6 16 19如果6-16出现异常们就会到19行。19行到最后可以保证在异常发生时正常解锁
19: astore_2 // e -> slot 2
20: aload_1 // <- lock引用
21: monitorexit // 将 lock对象 MarkWord 重置, 唤醒 EntryList
22: aload_2 // <- slot 2 (e)
23: athrow // throw e
24: return
Exception table:
from to target type
6 16 19 any
19 22 19 any
LineNumberTable:
line 8: 0
line 9: 6
line 10: 14
line 11: 24
LocalVariableTable:
Start Length Slot Name Signature
0 25 0 args [Ljava/lang/String;
StackMapTable: number_of_entries = 2
frame_type = 255 /* full_frame */
offset_delta = 19
locals = [ class "[Ljava/lang/String;", class java/lang/Object ]
stack = [ class java/lang/Throwable ]
frame_type = 250 /* chop */
offset_delta = 4
方法
https://blog.csdn.net/qq_35590091/article/details/106986641
synchronized经过编译之后,对应的是class文件中的monitorenter和monitorexit这两个字节码指令。这两个字节码对应的内存模型的操作是lock(上锁)和unlock(解锁)。因为这两个操作之间运行的都是原子的(这个操作保证了变量为一个线程独占的,也就是说只有获得锁的线程才能够操作被锁定的内存区域),所synchronized也具有原子性。
这两个字节码都需要一个对象来作为锁。因此,
1、如果synchronized修饰的是实例方法,则会传入this作为参数,
2、如果修饰的是静态方法,则会传入class类对象作为参数。
3、如果只是一个同步块,那么锁就是括号里配置的对象。
执行monitorenter字节码时,如果这个对象没有被上锁,或者当前线程已经持有了该锁,那么锁的计数器会+1,而在执行monitorexit字节码时,锁的计数器会-1,当计数器为0时,锁被释放。如果获取对象的锁失败,那么该线程会被阻塞等待,直到之前把这个对象上锁的线程释放这个锁为止。
每个对象都有一个monitor(监视器)与之关联,所谓的上锁,就是获得对象的monitor的独占权(因为只用获得monitor才能访问这个对象)。执行monitorenter字节码的时候,线程就会尝试获得monitor的所有权,也就是尝试获得对象的锁。只有获得了monitor,才能进入同步块,或者执行同步方法。独占对象的本质是独占对象的monitor。
**lock(上锁时)**清空工作内存中共享变量的值,从而使用共享变量时需要从主内存中重新获取最新的值;
unlock(解锁):这个操作规定,放开对某个变量的锁的之前,需要把这个变量从缓存更新到主内存。
因此它也具有可见性。
为什么synchronized无法禁止指令重排,却能保证有序性?因为在一个线程内部,他不管怎么指令重排,他都是as if serial的,也就是说单线程即使重排序之后的运行结果和串行运行的结果是一样的,是类似串行的语义。**而当线程运行到同步块时,会加锁,其他线程无法获得锁,也就是说此时同步块内的方法是单线程的,根据as if serial,可以认为他是有序的。**而指令重排序导致线程不安全是多线程运行的时候,不是单线程运行的时候,因此多线程运行时静止指令重排序也可以实现有序性,这就是volatile。
原子性 + 可见性 -> 有序性,即使内部重排序,也不会有影响,可以说是多线程的serif
锁的状态总共有四种,级别由低到高依次为:无锁、偏向锁、轻量级锁、重量级锁,四种状态会随着竞争的情况逐渐升级,而且是不可逆的过程。目的是为了提高获得锁和释放锁的效率。
偏向锁:大多数情况下,锁总是由同一个线程多次获得。当一个线程访问同步块并获取锁时,会在对象头和栈帧中的锁记录里存储锁偏向的线程ID,偏向锁是一个可重入的锁。如果锁对象头的Mark Word里存储着指向当前线程的偏向锁,无需重新进行CAS操作来加锁和解锁。当有其他线程尝试竞争偏向锁时,持有偏向锁的线程(不处于活动状态)才会释放锁。偏向锁无法使用自旋锁优化,因为一旦有其他线程申请锁,就破坏了偏向锁的假定进而升级为轻量级锁。
对于同一时刻只有一个线程访问时,每次进入锁是检查是否是自己的锁,是则执行,不是则升级
轻量级锁:减少无实际竞争情况下,使用重量级锁产生的性能消耗。JVM会现在当前线程的栈桢中创建用于存储锁记录的空间 LockRecord,将对象头中的 Mark Word 复制到 LockRecord 中并将 LockRecord 中的 Owner 指针指向锁对象。然后线程会尝试使用CAS将对象头中的Mark Word替换为指向锁记录的指针,成功则当前线程获取到锁,失败则表示其他线程竞争锁当前线程则尝试使用自旋的方式获取锁。自旋获取锁失败则锁膨胀升级为重量级锁。
在少量线程访问同步代码快时,使用CAS操作实现无,如果获取到则存入旧状态值,如果成功则使用自旋来获取锁,如果
重量级锁:通过对象内部的监视器(monitor)实现,其中monitor的本质是依赖于底层操作系统的Mutex Lock实 现,操作系统实现线程之间的切换需要从用户态到内核态的切换,切换成本非常高。线程竞争不使用自旋,不会消耗CPU。但是线程会进入阻塞等待被其他线程被唤醒,响应时间缓慢。
会调用操作系统层面的moniter
[1. 自旋锁](https://cyc2018.github.io/CS-Notes/#/notes/Java 并发?id=自旋锁)
让不满足条件的线程等待一会看能不能获得锁,通过占用处理器的时间来避免线程切换带来的开销。自旋等待的时间或次数是有一个限度的,如果自旋超过了定义的时间仍然没有获取到锁,则该线程应该被挂起。在 JDK1.6 之后,引入了自适应自旋锁,自适应意味着自旋的次数不是固定不变的,而是根据前一次在同一个锁上自旋的时间以及锁的拥有者的状态来决定。如果在同一个锁对象上,自旋等待刚刚成功获得过锁,并且持有锁的线程正在运行中,那么虚拟机就会认为这次自旋也是很有可能再次成功,进而它将允许自旋等待持续相对更长的时间。如果对于某个锁,自旋很少成功获得过,那在以后尝试获取这个锁时将可能省略掉自旋过程,直接阻塞线程,避免浪费处理器资源。
[2. 锁消除](https://cyc2018.github.io/CS-Notes/#/notes/Java 并发?id=锁消除)
锁消除是指对于被检测出不可能存在竞争的共享数据的锁进行消除。
锁消除主要是通过逃逸分析来支持,如果堆上的共享数据不可能逃逸出去被其它线程访问到,那么就可以把它们当成私有数据对待,也就可以将它们的锁进行消除。
对于一些看起来没有加锁的代码,其实隐式的加了很多锁。例如下面的字符串拼接代码就隐式加了锁:
public static String concatString(String s1, String s2, String s3) {
return s1 + s2 + s3;
}Copy to clipboardErrorCopied
String 是一个不可变的类,编译器会对 String 的拼接自动优化。在 JDK 1.5 之前,会转化为 StringBuffer 对象的连续 append() 操作:
public static String concatString(String s1, String s2, String s3) {
StringBuffer sb = new StringBuffer();
sb.append(s1);
sb.append(s2);
sb.append(s3);
return sb.toString();
}Copy to clipboardErrorCopied
每个 append() 方法中都有一个同步块。虚拟机观察变量 sb,很快就会发现它的动态作用域被限制在 concatString() 方法内部。也就是说,sb 的所有引用永远不会逃逸到 concatString() 方法之外,其他线程无法访问到它,因此可以进行消除。
[3.锁粗化](https://cyc2018.github.io/CS-Notes/#/notes/Java 并发?id=锁粗化)
如果一系列的连续操作都对同一个对象反复加锁和解锁,频繁的加锁操作就会导致性能损耗。
上一节的示例代码中连续的 append() 方法就属于这类情况。如果虚拟机探测到由这样的一串零碎的操作都对同一个对象加锁,将会把加锁的范围扩展(粗化)到整个操作序列的外部。对于上一节的示例代码就是扩展到第一个 append() 操作之前直至最后一个 append() 操作之后,这样只需要加锁一次就可以了。
volatile 本质是在告诉 JVM当前变量在寄存器(工作内存)中的值是不确定的,需要从主存中读取;synchronized 则是锁定当前变量,只有当前线程可以访问该变量,其他线程被阻塞住。
volatile 仅能使用在变量级别;synchronized 则可以使用在变量、方法、和类级别的。
volatile 仅能实现变量的修改可见性,不能保证原子性;而 synchronized 则可以保证变量的修改可见性和原子性。
volatile 不会造成线程的阻塞;synchronized 可能会造成线程的阻塞。
volatile 标记的变量不会被编译器优化;synchronized 标记的变量可以被编译器优化。