几个月前我们介绍了如何通过Plumbr来进行线程锁检测，随后便收到了很多类似的问题，“Hi，文章写得不错，现在我终于知道是什么引发的性能问题了，但是现在我该怎么做？”
为了在我们的产品中集成这个解决方案，我们付出了许多努力，不过在本文中，我想给大家分享几个常用的优化技巧，而不一定非要使用我们这款锁检测的工具。包括分拆锁，并发数据结构，保护数据而非代码，以及缩小锁的作用域。
锁无罪，竞争其罪
如果你在多线程代码中碰到了性能问题，你肯定会先抱怨锁。毕竟，从“常识”来讲，锁的性能是很差的，并且还限制了程序的可伸缩性。如果你怀揣着这样的想法去优化代码并删除锁的话，最后你肯定会引入一些难缠的并发BUG。
因此分清楚竞争锁与无竞争锁的区别是很有必要的。如果一个线程尝试进入另一个线程正在执行的同步块或者方法时，便会出现锁竞争。第二个线程就必须等待前一个线程执行完这个同步块并释放掉监视器（monitor）。如果只有一个线程在执行这段同步的代码，这个锁就是无竞争的。
事实上，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 */} } |
