Mysql 的 SELECT ... FOR UPDATE 语句是日常使用较多的用于锁定资源，确保在多个事务读取数据时始终能够读取到最新版本的数据的有效语句。那么它是怎么实现呢？在经过官网文档以及大量实践的验证之后发现网上存在大量不严谨甚至错误的信息，因此通过本文对 SELECT FOR UPDATE 语句作出以下总结。在具体介绍之前，先对目前网上教程或博客中会提到的几个常见误区进行纠正：

• SELECT FOR UPDATE 在xx情况下会添加表级锁。

  请注意，在任何情况下 SELECT FOR UPDATE 都不会添加表级锁。事实上，在大部分情况下（DQL 语句，DML 语句，DDL 语句）都不会添加表锁，取而代之的是各种类型的行锁。

    那么我们如何获取表锁呢？语句如下：

  1 2	LOCK TABLES xx READ; # 为 xx 表添加表级 S 锁 LOCK TABLES xx WRITE; # 为 xx 表添加表级 X 锁

  然后我们可以通过以下语句来检测当前 Mysql 有哪些表获取了表级锁

  1	SHOW OPEN TABLES WHERE In_use > 0

  更多的表级锁相关知识请参考官网介绍

• SELECT FOR UPDATE 在未使用索引时会”锁表”。

  SELECT FOR UPDATE 确实可以通过 Next-key lock 锁住所有记录和间隙来实现和表锁类似的效果。但未使用索引并非充分条件，我们判断 SELECT FOR UPDATE 是否锁住了所有数据和间隙还需要看它的隔离级别。

Semaphore，CountDownLatch，CyclicBarrier 均是 JDK1.5 提供的基础并发工具：

• Semaphore 是一个计数信号量，用于限制同时访问某个特定资源的数量
• CountDownLatch 是一个闭锁，允许一个或多个线程等待一组其他线程执行完成后执行，但只能使用一次
• CyclicBarrier 是一个循环栅栏，通过它可以实现让一组线程等待至某个状态之后再全部同时执行，并且支持重复使用

Semaphore

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class X{
    
    Random random = new Random();
    
    Semaphore semaphore = new Semaphore(10, true);

    // 方法本身控制同步
    public synchronized Integer getNextAvailableItem() throws InterruptedException {
        
        // 信号量控制访问次数
        semaphore.acquire();
        
        return random.nextInt();
    }

    public synchronized boolean markAsUnused(Integer item){
        
        // do something
        
        semaphore.release();
        
        return true;
    }
}

这是 Semaphore 的一个标准的使用方式，用于控制流量。上述程序创建了一个允许 10 个线程同时访问的信号量，并且使用公平锁（一般来说用于控制流量的使用需要使用公平模式，用于防止线程饥饿），然后在提供获取资源的接口 getNextAvailableItem 方法前先获取凭证，在释放资源后释放凭证。但是注意 Semaphore 不保证并发正确性，这需要接口自己保证，因此这里使用 synchronized 来提醒这一点。

  ReentrantLock 是基于 AQS 同步器实现的互斥锁，它支持设置公平锁/非公平锁模式，同时具有可重入性。在这里讨论 ReentrantLock 对这些特性的支持及应用。

标准模式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

class X {
    
    private final ReentrantLock lock = new ReentrantLock();
    
    public void m() {
    
        lock.lock();
        
        try {

            // ... method body
        
        } finally {
            
            lock.unlock();
        }
    }

}

  在 java.util.concurrent (JUC) 并发包中，如 ReentrantLock，Semaphore，CountDownLatch 等并发类的同步控制都是基于 AbstractQueuedSynchronizer (简称 AQS) 这个同步器抽象类来实现的。在这里较为深入的讨论同步器抽象类的实现原理与应用。

AQS简介

AbstractQueuedSynchronizer 内部维护着一个 FIFO 的 CLH 队列，队列中的每个 Node 代表着一个需要获取锁的线程

  自旋锁：自旋锁是指当一个线程尝试获取某个锁时，如果该锁已被其他线程占用，就一直循环检测锁是否被释放，而不是立刻进入线程挂起或睡眠状态。

• CLH 锁（Craig, Landin, and Hagersten locks）：基于链表的可扩展、高性能、公平的自旋锁，它不断轮询前驱的状态，如果发现前驱释放了锁就结束自旋
• MCS 锁：在当前结点自旋，但由前驱结点通知其结束自旋

AQS 采用的是一种变种的 CLH 队列锁：原始 CLH 是在前驱结点自旋，通过判断 pred.locked 来自旋，而 AQS 的 CLH 则是根据前驱结点的状态来控制阻塞，不会一直自旋。同时当前驱结点释放锁时会去唤醒该结点使其参与竞争锁。 AQS 的结点的定义如下：