Java中复杂的Synchronized关键字使用方法详解

 一、synchronized的特性

（1）互斥

synchronized 通过互斥达到原子性（线程安全的四大特性之一）

synchronized 会起到互斥效果，某个线程执行到某个对象的 synchronized 中时，其他线程如果也执行到同一个对象 synchronized 就会阻塞等待。同一时间，只能一个线程拥有这把锁，去执行代码。

1.进入 synchronized 修饰的代码块, 相当于 加锁。

2.退出 synchronized 修饰的代码块, 相当于 解锁。

synchronized void increase（）{//进入方法内部，相当于针对当前对象 
        count++;

}//执行完毕相当于针对当前对象“解锁”

synchronized用的锁是存在Java对象头里的。synchronized的底层是使用操作系统的mutex lock实现的。

可以粗略理解成, 每个对象在内存中存储的时候, 都存有一块内存表示当前的 "锁定" 状态。如果当前是 "未锁定" 状态, 那么就可以使用, 使用时需要设为 "锁定" 状态。如果当前是 "锁定" 状态, 那么其他人无法使用, 只能排队等待。一个线程先上了锁，其他线程只能等待这个线程释放。

注意点：

针对每一把锁，操作系统内部都维护了一个等待队列。当这个锁被某个线程占有的时候， 其他线程尝试进行加锁，就加不上了， 就会阻塞等待， 一直等到之前的线程解锁之后，由操作系统唤醒一个新的线程，再来获取到这个锁。

上一个线程解锁之后， 下一个线程并不是立即就能获取到锁。而是要靠操作系统来 "唤醒"。 这也就是操作系统线程调度的一部分工作。

假设有 A B C 三个线程，线程 A 先获取到锁，然后 B 尝试获取锁， 然后 C 再尝试获取锁，此时 B和 C 都在阻塞队列中排队等待。 但是当 A 释放锁之后, 虽然 B 比 C 先来的， 但是 B 不一定就能获取到锁， 而是和 C 重新竞争，并不遵守先来后到的规则。

（2）刷新内存

synchronized 通过加锁减锁能保证内存可见性。

synchronized 的工作过程:

1. 获得互斥锁

2. 从主内存拷贝变量的最新副本到工作的内存

3. 执行代码

4. 将更改后的共享变量的值刷新到主内存

5. 释放互斥锁

所以 synchronized 也能保证内存可见性。

（3）可重入

synchronized 只能有一定约束，并不能完全禁止指令重排序。synchronized 同步块对同一条线程来说是可重入的，不会出现自己把自己锁死的问题。

// 第一次加锁, 加锁成功
lock();
// 第二次加锁, 锁已经被占用, 阻塞等待.
lock();

对于把自己锁死，就是一个线程没有释放锁，然后又尝试再次加锁。

按照之前对于锁的设定， 第二次加锁的时候会阻塞等待。直到第一次的锁被释放， 才能获取到第二个锁。释放第一个锁也是由该线程来完成， 结果这个线程已经阻塞等待了，也就无法进行解锁操作。这时候就会死锁。这样的锁称为不可重入锁。

Java中的synchronized是可重入锁，因此不会出现上述问题。可重入锁的内部，包含了 "线程持有者" 和 "计数器" 两个信息。如果某个线程进行加锁的时候， 发现锁已经被人占用， 占用者恰好是自己，那么仍然可以继续获取到锁， 并让计数器自增。解锁的时候就是当计数器递减为0的时候， 才真正释放锁，这时候锁才能被别的线程获取到。

二、synchronized的使用

（1）修饰普通方法

锁的 SynchronizedDemo 对象

public class SynchronizedDemo {
    public synchronized void methond() {
    }
}

（2）修饰静态方法

锁的 SynchronizedDemo 类的对象

public class SynchronizedDemo {
    public synchronized static void method() {
    }
}

（3）修饰代码块

明确指定锁的对象

锁当前对象

public class SynchronizedDemo {
    public void method() {
    synchronized (this) {
        }
    }
}

锁类对象

public class SynchronizedDemo {
    public void method() {
        synchronized (SynchronizedDemo.class) {
        }
    }
}

需要注意的是两个线程竞争同一把锁，才会产生阻塞等待。两个线程分别尝试获取两把不同的锁，不会产生竞争。

三、synchronized的锁机制

（1）基本特点

只考虑 JDK 1.8，加锁工作过程：JVM 将 synchronized 锁分为 无锁、偏向锁、轻量级锁、重量级锁 状态。会根据情况，进行依次升级。

1. 开始时是乐观锁, 如果锁冲突频繁, 就转换为悲观锁.

2. 开始是轻量级锁实现, 如果锁被持有的时间较长, 就转换成重量级锁.

3. 实现轻量级锁的时候大概率用到的自旋锁策略

4. 是一种不公平锁

5. 是一种可重入锁

6. 不是读写锁

（2）加锁工作过程

1.偏向锁

第一个尝试加锁的线程，优先进入偏向锁状态。

偏向锁不是真的 "加锁"， 只是给对象头中做一个 "偏向锁的标记"，记录这个锁属于哪个线程。如果后续没有其他线程来竞争该锁，那么就不用进行其他同步操作了，避免了加锁解锁的开销。如果后续有其他线程来竞争该锁，因为刚才已经在锁对象中记录了当前锁属于哪个线程了， 很容易识别当前申请锁的线程是不是之前记录的线程， 那就取消原来的偏向锁状态， 进入一般的轻量级锁状态。偏向锁本质上相当于 "延迟加锁"。能不加锁就不加锁，尽量来避免不必要的加锁开销。但是该做的标记还是得做的， 否则无法区分何时需要真正加锁。

面试中会经常问到什么是偏向锁。偏向锁不是真的加锁，而只是在锁的对象头中记录一个标记，记录该锁所属的线程。如果没有其他线程参与竞争锁，那么就不会真正执行加锁操作，从而降低程序开销。一旦真的涉及到其他的线程竞争，再取消偏向锁状态，进入轻量级锁状态。

2.轻量级锁

随着其他线程进入竞争，偏向锁状态被消除， 进入轻量级锁状态(自适应的自旋锁)。

此处的轻量级锁就是通过 CAS 来实现。

通过 CAS 检查并更新一块内存 (比如 null => 该线程引用)。如果更新成功，则认为加锁成功。如果更新失败， 则认为锁被占用, 继续自旋式的等待(并不放弃 CPU)。

自旋操作是一直让 CPU 空转， 比较浪费 CPU 资源。因此此处的自旋不会一直持续进行， 而是达到一定的时间、重试次数, 就不再自旋了。也就是所谓的 "自适应"

3.重量级锁

如果竞争进一步激烈， 自旋不能快速获取到锁状态，就会膨胀为重量级锁。此处的重量级锁就是指用到内核提供的 mutex。

执行加锁操作， 先进入内核态。在内核态判定当前锁是否已经被占用。如果该锁没有占用， 则加锁成功， 并切换回用户态。如果该锁被占用，则加锁失败。 此时线程进入锁的等待队列、挂起。 等待被操作系统唤醒。经历了一系列的操作， 这个锁被其他线程释放了， 操作系统也想起了这个挂起的线程，于是唤醒。这个线程， 尝试重新获取锁。

（3）优化操作

1.锁消除

编译器+JVM 判断锁是否可消除。 如果可以， 就直接消除。

锁消除：有些应用程序的代码中, 用到了 synchronized， 但其实没有在多线程环境下。 (例如StringBuffer)此时每个 append 的调用都会涉及加锁、解锁。但如果只是在单线程中执行这个代码， 那么这些加锁解锁操作是没有必要的,，白白浪费了一些资源开销。可以进行消除操作。
StringBuffer sb = new StringBuffer();
sb.append("a");
sb.append("b");
sb.append("c");
sb.append("d");

2.锁粗化

一段逻辑中如果出现多次加锁解锁，编译器 + JVM 会自动进行锁的粗化。

锁的粒度: 粗和细

实际开发过程中，使用细粒度锁，是期望释放锁的时候其他线程能使用锁。但是实际上可能并没有其他线程来抢占这个锁。这种情况 JVM 就会自动把锁粗化， 避免频繁申请释放锁。例如给下属交代工作任务：方式一：打电话，交代任务1, 挂电话。打电话，交代任务2，挂电话。打电话， 交代任务3， 挂电话。方式二：打电话，交代任务1，任务2，任务3，挂电话。显然，方式二是更高效的方案。这就是锁粗化的一个过程。

四、synchronized和volatile的区别

synchronized和volatile都是Java关键字，并且都是解决线程安全的方式，所以在面试的时候经常会被放到一起问。

两者其实并没有联系。

synchronized:

1.通过加锁、解锁的方式，把一堆代码绑在一起，来保证原子性。

2.通过加锁、解锁的方式， 来保证内存可见性。

3.对指令重排序有一定约束。

volatile：

1.不能保证原子性。

2.保证内存可见性。

3.禁止指令重排序。       

虽然synchronized在大多数情况下，都可以保证线程安全的。但是也不能在任何情况下都用synchronized的。synchronized是要付出一定代价的。synchronized是通过加锁、解锁的方式来保证的。所以，其他线程抢不到锁的时候，线程就会阻塞。线程就会放弃CPU，放弃之后，被重新调用的时间是不确定的。当使用synchronized就一定程度上放弃了高性能。使用volatile不会造成线程阻塞，但对性能也有一定影响，不过没有synchronized影响大。

使用多线程是为了提高效率。使用synchronized，就代表放弃了一定效率。这两者需要平衡。    

附：synchronized同步语句块比synchronized修饰方法的优势

用关键字synchronized修饰方法简单粗暴，可以很方便的达到同步效果，但是修饰方法往往是有弊端的：一是对性能的影响，方法体通常很长，其他对象都要等得到锁的那个对象释放锁可能是一个漫长的过程。二是灵活性没有锁代码块好，synchronized修饰方法就是给方法所在的对象上锁，而synchronized代码块有一个参数，可以传一个对象进去，这个对象可以是this对象，也可以是其他对象，传入的对象也就是需要上锁的对象。

当一个线程访问某个对象的同步代码块时，另一个线程仍然可以访问这个对象中非同步代码块部分。也就是说：不在synchronized代码块中就是异步执行，在synchronized代码块中就是同步执行。

但是还有一个问题，在一个方法里面，如果同步代码块在中间，那么多个线程调用的时序是怎样的呢？答案是，在synchronized同步代码块之前的代码会异步执行，不受时间控制，但是在synchronized中的代码以及synchronized代码块之后的代码都需要排队的。

总结

到此这篇关于Java中复杂的Synchronized关键字使用方法的文章就介绍到这了,更多相关Java Synchronized关键字内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！

最新评论