java锁性能对比_提高Java的锁性能

java锁性能对比

Plumbr是唯一可以通过解释应用程序性能数据来自动检测Java性能问题根本原因的解决方案。

几个月前，我们在Plumbr中引入了锁定线程检测之后，我们开始收到类似于“嘿，太好了，现在我知道是什么导致了性能问题，但是现在应该做什么？”这样的查询。

我们正在努力将解决方案说明构建到我们自己的产品中，但是在这篇文章中，我将分享一些可以独立于用于检测锁的工具应用的常见技术。这些方法包括锁拆分，并发数据结构，保护数据（而不是代码）和减少锁范围。

锁不是邪恶的，锁争用是

每当您遇到线程代码的性能问题时，就有机会开始指责锁。毕竟，常见的“知识”是锁很慢并且限制了可伸缩性。因此，如果您具备了这种“知识”并开始优化代码并摆脱了锁，那么您最终有可能引入令人讨厌的并发错误，这些错误将在以后出现。

因此，了解竞争锁和非竞争锁之间的区别非常重要。当一个线程试图进入另一个线程当前执行的同步块/方法时，发生锁争用。现在，第二个线程被迫等待，直到第一个线程完成了执行同步块并释放监视器为止。当一次仅一个线程试图执行同步代码时，锁保持无竞争状态。

实际上，JVM中的同步针对无竞争的情况进行了优化，并且对于绝大多数应用程序而言，无竞争的锁几乎在执行期间没有开销。因此，它不是性能应归咎的锁，而是争执的锁。有了这些知识，让我们看看如何减少争用的可能性或减少争用的时间。

保护数据而不是代码

实现线程安全的一种快速方法是锁定对整个方法的访问。例如，请看以下示例，该示例说明了构建在线扑克服务器的幼稚尝试：

class GameServer {public Map<<String, List<Player>> tables = new HashMap<String, List<Player>>();public synchronized void join(Player player, Table table) {if (player.getAccountBalance() > table.getLimit()) {List<Player> tablePlayers = tables.get(table.getId());if (tablePlayers.size() < 9) {tablePlayers.add(player);}}}public synchronized void leave(Player player, Table table) {/*body skipped for brevity*/}public synchronized void createTable() {/*body skipped for brevity*/}public synchronized void destroyTable(Table table) {/*body skipped for brevity*/}
}

作者的初衷是好的–当新玩家加入桌台时，必须保证坐在桌旁的玩家人数不会超过9人。

但是，只要这样的解决方案实际上负责使玩家坐在桌子上（即使是在流量适中的扑克场所），该系统注定要通过等待释放锁的线程不断触发争用事件。锁定块包含帐户余额和表限制检查，这可能会涉及昂贵的操作，从而增加争用的可能性和持续时间。

解决方案的第一步是通过将同步从方法声明移到方法主体，确保我们保护数据，而不是代码。在上面的简约示例中，它可能一开始并没有太大变化。但是让我们考虑整个GameServer接口，而不仅仅是单个join（）方法：

class GameServer {public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();public void join(Player player, Table table) {synchronized (tables) {if (player.getAccountBalance() > table.getLimit()) {List<Player> tablePlayers = tables.get(table.getId());if (tablePlayers.size() < 9) {tablePlayers.add(player);}}}}public void leave(Player player, Table table) {/* body skipped for brevity */}public void createTable() {/* body skipped for brevity */}public void destroyTable(Table table) {/* body skipped for brevity */}
}

原本似乎是次要的变化，现在影响了整个班级的行为。每当玩家加入表时，先前同步的方法就会锁定在GameServer实例（ this ）上，并向试图同时离开 table （）表的玩家引入竞争事件。将锁从方法签名移到方法主体可推迟锁定并减少争用可能性。

缩小锁定范围

现在，在确保它是我们实际保护的数据而不是代码之后，我们应该确保我们的解决方案仅锁定必要的内容，例如，当上面的代码如下重写时：

public class GameServer {public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();public void join(Player player, Table table) {if (player.getAccountBalance() > table.getLimit()) {synchronized (tables) {List<Player> tablePlayers = tables.get(table.getId());if (tablePlayers.size() < 9) {tablePlayers.add(player);}}}}//other methods skipped for brevity
}

那么检查玩家帐户余额的潜在耗时操作（可能涉及IO操作）现在已超出锁定范围。注意，引入该锁仅是为了防止超出表的容量，并且帐户余额检查也不是该保护措施的一部分。

开锁

当我们看最后一个代码示例时，您可以清楚地注意到整个数据结构都受同一锁保护。考虑到我们可能在这种结构中容纳成千上万张扑克桌，由于我们必须分别保护每张桌子以防容量溢出，因此它仍然会带来争用事件的高风险。

为此，有一种简单的方法可以在每个表中引入单个锁，例如以下示例：

public class GameServer {public Map<String, List<Player>> tables = new HashMap<String, List<Player>>();public void join(Player player, Table table) {if (player.getAccountBalance() > table.getLimit()) {List<Player> tablePlayers = tables.get(table.getId());synchronized (tablePlayers) {if (tablePlayers.size() < 9) {tablePlayers.add(player);}}}}//other methods skipped for brevity
}

现在，如果我们仅同步访问同一表而不是所有表的访问 ，则可以大大降低锁争用的可能性。例如，在我们的数据结构中有100个表，争用的可能性现在比以前小100倍。

使用并发数据结构

另一个改进是删除传统的单线程数据结构，并使用为并行使用而明确设计的数据结构。例如，当选择ConcurrentHashMap来存储所有扑克表时，将导致类似于以下代码：

public class GameServer {public Map<String, List<Player>> tables = new ConcurrentHashMap<String, List<Player>>();public synchronized void join(Player player, Table table) {/*Method body skipped for brevity*/}public synchronized void leave(Player player, Table table) {/*Method body skipped for brevity*/}public synchronized void createTable() {Table table = new Table();tables.put(table.getId(), table);}public synchronized void destroyTable(Table table) {tables.remove(table.getId());}
}

由于我们需要保护单个表的完整性，因此join（）和leave（）方法中的同步仍然像我们之前的示例中那样。因此， ConcurrentHashMap在这方面没有帮助。但是，由于我们还在createTable（）和destroyTable（）方法中创建新表并销毁表，因此对ConcurrentHashMap的所有这些操作都是完全并发的，从而允许增加或减少并行表的数量。