<强> java中锁的性能提高办法
我们努力为自己的产品所遇到的问题思考解决办法,但在这篇文章中我将给大家分享几种常用的技术,包括分离锁,并行数据结构,保护数据而非代码,缩小锁的作用范围,这几种技术可以使我们不使用任何工具来检测死锁。
<强>锁不是问题的根源,锁之间的竞争才是
通常在多线程的代码中遇到性能方面的问题时,一般都会抱怨是锁的问题。毕竟锁会降低程序的运行速度和其较低的扩展性是众所周知的。因此,如果带着这种”常识“开始优化代码,其结果很有可能是在之后会出现讨人厌的并发问题。
因此,明白竞争锁和非竞争锁的不同是非常重要的。当一个线程试图进入另一个线程正在执行的同步块或方法时会触发锁竞争。该线程会被强制进入等待状态,直到第一个线程执行完同步块并且已经释放了监视器。当同一时间只有一个线程尝试执行同步的代码区域时,锁会保持非竞争的状态。
事实上,在非竞争的情况下和大多数的应用中,JVM已经对同步进行了优化。非竞争锁在执行过程中不会带来任何额外的开销。因此,你不应该因为性能问题抱怨锁,应该抱怨的是锁的竞争。当有了这个认识之后,让我们来看下能做些什么,以降低竞争的可能性或减少竞争的持续时间。
<>强保护数据而非代码
解决线程安全问题的一个快速的方法就是对整个方法的可访问性加锁,例如下面这个例子,试图通过这种方法来建立一个在线扑克游戏服务器:
作者的意图是好的,当一个新的玩家加入牌桌时,必须确保牌桌上的玩家个数不会超过牌桌可以容纳的玩家总个数9 .
但是这种解决办法事实上无论何时都要对玩家进入牌桌进行控制,即使是在服务器的访问量较小的时候也是这样,那些等待锁释放的线程注定会频繁的触发系统的竞争事件。包含对账户余额和牌桌限制检查的锁定块很可能大幅提高调用操作的开销,而这无疑会增加竞争的可能性和持续时间。
解决的第一步就是确保我们保护的是数据,而不是从方法声明移到方法体中的那段同步声明。对于上面那个简单的例子来说,可能改变不大。但是我们要站在整个游戏服务的接口之上来考虑,而不是单单的一个连接()方法。
原本可能只是一个小小的改变,影响的可是整个类的行为方式。玩家无论何时加入牌桌,先前的同步方法都会对整个GameServer实例加锁,进而会与那些同时试图离开牌桌的玩家产生竞争。将锁从方法声明移到方法体中会延迟锁的加载,进而降低了锁竞争的可能性。
<强>缩小锁的作用范围
现在,当确信了需要保护的是数据而非程序后,我们应该确保我们只在必要的地方加锁,例如当上面的代码被重构之后:
