重新学习Java线程原语

Synchronized曾经是一个革命性的技术，在当前仍然有重要的用途。但是，现在是时候转向更新的Java线程原语，同时重新考虑我们的核心逻辑。

自从Java第一个测试版以来，我就一直在使用它。从那时起，线程就是我最喜欢的特性之一。Java是第一种在编程语言本身中引入线程支持的语言。那是一个具有争议的决定。在过去的十年中，每种编程语言都竞相引入async/await，甚至Java也有一些第三方支持......但是Java选择了引入更优越的虚拟线程（Loom项目）。本文并不讨论这个问题。

我觉得这很好，证明了Java的核心实力。Java不仅仅是一种语言，还是一种文化。这种文化注重深思熟虑的变革，而不是盲目跟随时尚潮流。

在本文中，我想重新探讨Java中的线程编程旧方法。我习惯使用synchronized、wait、notify等技术。但是， “然而，这些方法已经不再是Java中线程处理的最佳方式。 我也是问题的一部分。我还是习惯于使用这些技术，发现很难适应自Java 5以来就存在的一些API。这是一种习惯的力量。 虽然可以讨论许多处理线程的出色API，但我想在这里专注讨论锁，因为它们是基础但极为重要的。

Synchronized 与 ReentrantLock

我犹豫放弃使用 synchronized 的原因是，并没有更好的替代方案。现在弃用 synchronized 的主要原因是，它可能会在 Loom 中触发线程固定，这并不理想。JDK 21 可能会修复这个问题（当 Loom 正式发布时），但还有一些理由弃用它。

synchronized 的直接替代品是 ReentrantLock。不幸的是，ReentrantLock 相比 synchronized 很少有优势，因此迁移的好处最多是存疑的。事实上，它有一个主要的缺点。为了了解这一点，让我们看一个例子。下面是我们如何使用 synchronized：

synchronized(LOCK) {
    // safe code
}

LOCK.lock();
try {
    // safe code
} finally {
    LOCK.unlock();
}

ReentrantLock 的第一个缺点是冗长。我们需要try块，因为如果在块内部发生异常，锁将保持。而 synchronized 则会自动处理异常。

有些人会使用 AutoClosable 对锁进行封装，大概是这样的：

public class ClosableLock implements AutoCloseable {
   private final ReentrantLock lock;

   public ClosableLock() {
       this.lock = new ReentrantLock();
   }

   public ClosableLock(boolean fair) {
       this.lock = new ReentrantLock(fair);
   }

   @Override
   public void close() throws Exception {
       lock.unlock();
   }

   public ClosableLock lock() {
       lock.lock();
       return this;
   }

   public ClosableLock lockInterruptibly() throws InterruptedException {
       lock.lock();
       return this;
   }

   public void unlock() {
       lock.unlock();
   }
}

注意，我没有实现 Lock 接口，这本来是最理想的。这是因为 lock 方法返回了可自动关闭的实现，而不是 void。

一旦我们这样做了，我们就可以编写更简洁的代码，比如这样：

try(LOCK.lock()) {
 // safe code
}

我喜欢代码更简洁的写法，但是这个方法存在一些问题，因为 try-with-resource 语句是用于清理资源的，而我们正在重复使用锁对象。虽然调用了 close 方法，但是我们会再次在同一个对象上调用它。我认为，将 try-with-resource 语法扩展到支持锁接口可能是个好主意。但在此之前，这个技巧可能不值得采用。

ReentrantLock 的优势

使用ReentrantLock的最大原因是Loom支持。其他的优点也不错，但没有一个是“杀手级功能”。

我们可以在方法之间使用它，而不是在一个连续的代码块中使用。但是这可能不是一个好主意，因为你希望尽量减少锁定区域，并且失败可能会成为一个问题。我不认为这个特性是一个优点。

ReentrantLock提供了公平锁（fairness）的选项。这意味着它会先服务于最先停在锁上的线程。我试图想到一个现实而简单的使用案例，但却无从下手。如果您正在编写一个复杂的调度程序，并且有许多线程不断地排队等待资源，您可能会发现一个线程由于其他线程不断到来而被“饥饿”。但是，这种情况可能更适合使用并发包中的其他选项。也许我漏掉了什么……

lockInterruptibly() 方法允许我们在线程等待锁时中断它。这是一个有趣的特性，但是很难找到一个真正实际应用场景。如果你编写的代码需要非常快速响应中断，你需要使用 lockInterruptibly() API 来获得这种能力。但是，你通常在 lock()方法内部花费多长时间呢？

这种情况可能只在极端情况下才会有影响，大多数人在编写高级多线程代码时可能不会遇到这种情况。

ReadWriteReentrantLock

更好的方法是使用ReadWriteReentrantLock。大多数资源都遵循频繁读取、少量写入的原则。由于读取变量是线程安全的，除非正在写入变量，否则没有必要加锁。这意味着我们可以将读取操作进行极致优化，同时稍微降低写操作的速度。

假设这是你的使用情况，你可以创建更快的代码。使用读写锁时，我们有两个锁，一个读锁，如下图所示。它允许多个线程通过，实际上是“自由竞争”的。

一旦我们需要写入变量，我们需要获得写锁，如下图所示。我们尝试请求写锁，但仍有线程从变量中读取，因此我们必须等待。

一旦所有线程完成读取，所有读取操作都会阻塞，写入操作只能由一个线程执行，如下图所示。一旦释放写锁，我们将回到第一张图中的“自由竞争”状态。

这是一种强大的模式，我们可以利用它使集合变得更快。一个典型的同步列表非常慢。它同步所有的操作，包括读和写。我们有一个CopyOnWriteArrayList，它对于读取操作非常快，但是任何写入操作都很慢。

如果可以避免从方法中返回迭代器，你可以封装列表操作并使用这个API。例如，在以下代码中，我们将名字列表暴露为只读，但是当需要添加名字时，我们使用写锁。这可以轻松超过synchronized列表的性能：

private final ReadWriteLock LOCK = new ReentrantReadWriteLock();
private Collection<String> listOfNames = new ArrayList<>();
public void addName(String name) {
   LOCK.writeLock().lock();
   try {
       listOfNames.add(name);
   } finally {
       LOCK.writeLock().unlock();
   }
}
public boolean isInList(String name) {
   LOCK.readLock().lock();
   try {
       return listOfNames.contains(name);
   } finally {
       LOCK.readLock().unlock();
   }
}

这个方案可行，因为synchronized是可重入的。我们已经持有锁，所以从methodA()进入methodB()不会阻塞。这在使用ReentrantLock时也同样适用，只要我们使用相同的锁或相同的synchronized对象。

StampedLock返回一个戳记（stamp），我们用它来释放锁。因此，它有一些限制，但它仍然非常快和强大。它也包括一个读写戳记，我们可以用它来保护共享资源。但ReadWriteReentrantLock不同的是，它允许我们升级锁。为什么需要这样做呢？

看一下之前的addName()方法...如果我用"Shai"两次调用它会怎样？

是的，我可以使用Set...但是为了这个练习的目的，让我们假设我们需要一个列表...我可以使用ReadWriteReentrantLock编写那个逻辑：

public void addName(String name) {
   LOCK.writeLock().lock();
   try {
       if(!listOfNames.contains(name)) {
           listOfNames.add(name);
       }
   } finally {
       LOCK.writeLock().unlock();
   }
}

这很糟糕。我“付出”写锁只是为了在某些情况下检查contains()（假设有很多重复项）。我们可以在获取写锁之前调用isInList(name)。然后我们会：

• 获取读锁
• 释放读锁
• 获取写锁
• 释放写锁

在两种情况下，我们可能会排队, 这样可能会增加额外的麻烦，不一定值得。

有了StampedLock，我们可以将读锁更新为写锁，并在需要的情况下立即进行更改，例如：

public void addName(String name) {
   long stamp = LOCK.readLock();
   try {
       if(!listOfNames.contains(name)) {
           long writeLock = LOCK.tryConvertToWriteLock(stamp);
           if(writeLock == 0) {
               throw new IllegalStateException();
           }
           listOfNames.add(name);
       }
   } finally {
       LOCK.unlock(stamp);
   }
}

这是针对这些情况的一个强大的优化。

终论

我经常不假思索地使用 synchronized 集合，这有时可能是合理的，但对于大多数情况来说，这可能是次优的。通过花费一点时间研究与线程相关的原语，我们可以显著提高性能。特别是在处理 Loom 时，其中底层争用更为敏感。想象一下在 100 万并发线程上扩展读取操作的情况...在这些情况下，减少锁争用的重要性要大得多。

你可能会想，为什么 synchronized 集合不能使用 ReadWriteReentrantLock 或者是 StampedLock 呢？

这是一个问题，因为API的可见接口范围非常大，很难针对通用用例进行优化。这就是控制低级原语的地方，可以使高吞吐量和阻塞代码之间的差异。

---

【注】本文译自： Relearning Java Thread Primitives - DZone