Java并发读书笔记：线程安全与互斥同步

目录

• 导致线程不安全的原因
• 什么是线程安全
  • 不可变
  • 绝对线程安全
  • 相对线程安全
  • 线程兼容
  • 线程对立
• 互斥同步实现线程安全
  • synchronized内置锁
    • 锁即对象
    • 是否要释放锁
    • 实现原理
    • 啥是重进入？
  • ReentrantLock（重入锁）
    • API层面的互斥锁
    • 等待可中断
    • 公平锁
    • 锁绑定

本篇参考许多著名的书籍，形成读书笔记，便于加深记忆。

前文传送门：Java并发读书笔记：JMM与重排序

导致线程不安全的原因

当一个变量被多个线程读取，且至少被一个线程写入时，如果读写操作不遵循happens-before规则，那么就会存在数据竞争的隐患，如果不给予正确的同步手段，将会导致线程不安全。

什么是线程安全

Brian Goetz在《Java并发编程实战》中是这样定义的：

当多个线程访问一个类时，如果不用考虑这些线程在运行时环境下的调度和交替执行，并且不需要额外的同步及在调用方代码不必做其他的协调，这个类的行为仍然是正确的，那么这个类就是线程安全的。

---

周志明在《深入理解Java虚拟机》中提到：多个线程之间存在共享数据时，这些数据可以按照线程安全程度进行分类：

不可变

不可变的对象一定是线程安全的，只要一个不可变的对象被正确地构建出来，那么它在多个线程中的状态就是一致的。例如用final关键字修饰对象：

• 修饰的是基本数据类型，final修饰不可变。
• 修饰的是一个对象，就需要保证其状态不发生变化。

JavaAPI中符合不可变要求的类型：String类，枚举类，数值包装类型（如Double）和大数据类型（BigDecimal)。

绝对线程安全

即完全满足上述对于线程安全定义的。

满足该定义其实需要付出很多代价，Java中标注线程安全的类，实际上绝大多数都不是线程安全的（如Vector），因为它仍需要在调用端做好同步措施。Java中绝对线程安全的类：CopyOnWriteArrayList、CopyOnWriteArraySet。

相对线程安全

即我们通常所说的线程安全，Java中大部分的线程安全类都属于该范畴，如Vector，HashTable，Collections集合工具类的synchronizedCollection()方法包装的集合等等。就拿Vector举例：如果有个线程在遍历某个Vector、有个线程同时在add这个Vector，99%的情况下都会出现ConcurrentModificationException，也就是fail-fast机制。

线程兼容

对象本身并不是线程安全的，可以通过在调用段正确同步保证对象在并发环境下安全使用。如我们之前学的分别与Vector和HashTable对应的ArrayList和HashMap。

---

对象通过synchronized关键字修饰，达到同步效果，本身是安全的，但相对来说，效率会低很多。

线程对立

无论调用端是否采取同步措施，都无法正确地在多线程环境下执行。Java典型的线程对立：Thread类中的suspend()和resume()方法：如果两个线程同时操控一个线程对象，一个尝试挂起，一个尝试恢复，将会存在死锁风险，已经被弃用。

常见的对立：System.setIn()，System.setOut()和System.runFinalizersOnExit()。

互斥同步实现线程安全

互斥同步也被称做阻塞同步(因为互斥同步会因为线程阻塞和唤醒产生性能问题），它是实现线程安全的其中一种方法，还有一种是非阻塞同步，之后再做学习。

互斥同步：保证并发下，共享数据在同一时刻只被一个线程使用。

synchronized内置锁

其中使用synchronized关键字修饰方法或代码块是最基本的互斥同步手段。

synchronized是Java提供的一种强制原子性的内置锁机制，以synchronized代码块的定义方式来说：

synchronized(lock){
    //访问或修改被锁保护的共享状态
}

它包含了两部分：1、锁对象的引用 2、锁保护的代码块。

每个Java对象都可以作为用于同步的锁对象，我们称该类的锁为监视器锁（monitor locks），也被称作内置锁。

可以这样理解：线程在进入synchronized之前需要获得这个锁对象，在线程正常结束或者抛出异常都会释放这个锁。

而这个锁对象很好地完成了互斥，假设A持有锁，这时如果B也想访问这个锁，B就会陷入阻塞。A释放了锁之后，B才可能停止阻塞。

锁即对象

• 对于普通同步方法，锁是当前实例对象（this）。

//普通同步方法
public synchronized void do(){}

• 对于静态同步方法，锁是当前的类的Class对象。

//静态同步方法
public static synchronized void f(){}

• 对于同步方法块，锁的是括号里配置的对象。

//锁对象为TestLock的类对象
synchronized (TestLock.class){
    f();
}

明确：synchronized方法和代码块本质上没啥不同，方法只是对跨越整个方法体的代码块的简短描述，而这个锁是方法所在对象本身（static修饰的方法，对象是当前类对象）。这个部分可以参考：Java并发之synchronized深度解析

是否要释放锁

释放锁的情况：

• 线程执行完毕。
• 遇到return、break终止。
• 抛出未处理的异常或错误。
• 调用了当前对象的wait()方法。

不释放锁的情况：

• 调用了Thread.sleep()和Thread.yield()暂停执行不会释放锁。
• 调用suspend()挂起线程，不会释放锁，已被弃用。

实现原理

通过对.class文件反编译可以发现，同步方法通过ACC_SYNCHRONIZED修饰，代码块同步使用monitorenter和monitorexit两个指令实现。

虽然两者实现细节不同，但其实本质上都是JVM基于进入和退出Monitor对象来实现同步，JVM的要求如下：

• monitorenter指令会在编译后插入到同步代码块的开始位置，而monitorexit则会插入到方法结束和异常处。

• 每个对象都有一个monitor与之关联，且当一个monitor被持有之后，他会处于锁定状态。

• 线程执行到monitorenter时，会尝试获取对象对应monitor的所有权。

• 在获取锁时，如果对象没被锁定，或者当前线程已经拥有了该对象的锁（可重进入，不会锁死自己），将锁计数器加一，执行monitorexit时，锁计数器减一，计数为零则锁释放。

• 获取对象锁失败，则当前线程陷入阻塞，直到对象锁被另外一个线程释放。

啥是重进入？

重进入意味着：任意线程在获取到锁之后能够再次获取该锁而不会被锁阻塞，synchronized是隐式支持重进入的，因此不会出现锁死自己的情况。

这就体现了锁计数器的作用：获得一次锁加一，释放一次锁减一，无论获得还是释放多少次，只要计数为零，就意味着锁被成功释放。

ReentrantLock（重入锁）

ReentrantLock位于java.util.concurrent（J.U.C）包下，是Lock接口的实现类。基本用法与synchronized相似，都具备可重入互斥的特性，但拥有扩展的功能。

Lock接口的实现提供了比使用synchronized方法和代码块更广泛的锁操作。允许更灵活的结构，具有完全不同的属性，并且可能支持多个关联的Condition对象。

RenntrantLock官方推荐的基本写法：

class X {
    //定义锁对象
    private final ReentrantLock lock = new ReentrantLock();
    // ...
    //定义需要保证线程安全的方法
    public void m() {
        //加锁
        lock.lock();
        try{
        // 保证线程安全的代码
        }
        // 使用finally块保证释放锁
        finally {
            lock.unlock()
        }
    }
}

API层面的互斥锁

ReentrantLock表现为API层面的互斥锁，通过lock()和unlock()方法完成，是显式的，而synchronized表现为原生语法层面的互斥锁，是隐式的。

等待可中断

当持有线程长期不释放锁的时候，正在等待的线程可以选择放弃等待或处理其他事情。

公平锁

ReentrantLock锁是公平锁，即保证等待的多个线程按照申请锁的时间顺序依次获得锁，而synchronized是不公平锁。

锁绑定

一个ReentrantLock对象可以同时绑定多个Condition对象。

---

JDK1.6之前，ReentrantLock在性能方面是要领先于synchronized锁的，但是JDK1.6版本实现了各种锁优化技术，后续性能改进会更加偏向于原生的synchronized。

参考数据：《Java并发编程实战》、《Java并发编程的艺术》、《深入理解Java虚拟机》