Java延时实例分析：LockvsSynchronized-Java开发Java经验技巧

1、java延时实例分析：lock vs synchronized -编程 开发技术java延时实例分析：lock vssynchronized本文ill importnew - paddx翻译自javacodegeeks«欢迎加入翻译小组。转载诘见文末要求。这篇文章通过实例讨论了：- java, concurrent. lock 创建的垃圾- 比较 lock 和 synchronized-如何通过编程方式计算延时-lock和synchronized竞争带来的影响-延迟测试屮由于遗漏（co-ordinated omission）可能对结果的影响冋到我最喜欢的一个主题：垃圾的创建与分配。可

2、以从我以前的文章（如：性能 优化的首要法则和重视性能优化首要法则：逃逸分析的效果）获取更多关于这个 议题的细节。尤其弄懂在性能问题上，为什么分配是如此重要的因索。几天前，当我诊断一些jit编译期间奇怪的分配问题时，发现java. util, concurrent, locks. reentrantlock 的分配有问题,不过这只在竞争 条件下出现。（这一点很容易证明，只要运行一个在lock上建立竞争并指定 -verbosegc参数测试程序（类似下面的程序）。示例是在有lock竞争时gc的输出结果：gc (allocation failure) gc (allocation failure) g

3、c (allocation failure) gc (allocation fa订ure) gc (al location failure) gc (allocation failure) gc (allocation failure) gc (allocation failure) gc (allocation failure)16384k-1400k(62976k),17784k->1072k(62976k),17456k->1040k(62976k),17424k->1104k(62976k),17488k->1056k(61952k),17440k->10

4、24k(61952k),17408k->1161k(61952k), 17545k->1097k(61440k), 16969k->1129k(61952k),0.0016854 secs0.0011939 secs0.0008452 secs0.0008338 secs0.0008799 secs0.0010529 secs0.0012381 secs0.0004592 secs0.0004500 secsgc (allocation failure)17001k->1129k(61952k),0.0003857 secs我怀疑是否是在垃圾回收时必须对清理lock上分

5、配的空间，在高度竞争的环境 下，将会选择一种比内建的'synchronized '更坏的同步策略。当然，这个问题比其他任何问题都更加学术。如呆你确实非常关心延迟，你会发 现自己从来不会(或者绝不应该)有这样一种情况会需要这么多的线程锁。不过, 请继续跟我-起探究这个问题，因为这个过程和结果都非常有趣。简史：锁是2004年，在java 1.5中引入的。由于对简单并发结构的迫切需要， 锁以及其他并发工具因此而诞生。在这z前，你不得不通过内建的synchronized 和object的wait () > notify ()方法来控制并发。reentrantlock提供许多比sy

6、nchronized更好的功能，下面是一些例子：变得非结构化比如，不会受块或方法的限制，允许你跨多个方法持有锁。 轮询锁等待锁超时 配置失败策略但是它们在延迟测试屮有什么作用呢？我写了一个简单的测试来比较lock和synchronized的性能。这段代码允许改变线程的数量(1个线程意味着不存在竞争)及竞争的数量。通 过有遗漏(coordinated omission)和没有遗漏來衡量。采用lock或者synchronised来运行测试。为了记录结果,我使用了 histogram类。该类是peter lawrey创建的。你可 以在chronicle-core的工具类中找到该类。import or

7、g. junit.test;import java uti1. concurrcnt. locks lock;import java uti1. concurrent. locks reentrantlock;public class lockvssync private static final boolean c00rdtnated_0mtsst0n 二 boolcan.gctboolcan("coordinatcdomission");/either run testing lock or testing synchronizedprivate static fina

8、l boolean is lock = boolean. getboolean(，zislock，z);private static final int numthreads 二integer, getlnteger ("numthreeids");<a href=，http:/wvw. jobbole. com/members/madao, >test</a> public void test() throws interruptedexception lock lock 二 new reentrantlock();for (int t 二 0;

9、t &lt; num_threads; t+) if (t = 0) /set the first thread as the master which will bemeasured设置第一个线程作为测量的线程contention/the other threads are only to cause其他线程只是引起竞争runner r = new runner (lock, true);r. start (); else runner r = new runner (lock, false);r. start ();synchroni7ed(this) /hold the main

10、 thrcad from complcting wait ();iprivate void tcstlock(lock rlock) rlock. lock();try for (int i 二 0; i &lt; 2; i+) double x 二 10 / 4. 5 + i; finally rlock. unlock ();private synchronized void testsync() for (int i = 0; i &lt; 2; i+) double x 二 10 / 4. 5 + i;class runner extends thread privat

11、e lock lock;private boolean master;public runner (lock lock, boolean master) this, lock = lock; this, master 二 master;©override public void run() histogram histogram = null;if (master) histogram = new histogramo ;long rate 二 1000;/expect 1 every microsecondlong now =0;for (int i = -10000; i 0)i

12、f(!coordinated_omission) now +二 rate;whi le (system. nanotimeo 二0 & amp; &amp; master) histogram sample (system nanotime() 一 now);if (master) system, out. println(histogram. tomicrosformat(); system, exit(0);结果如下：这是没有遗漏(co-ordinated omission)的结果：釆用微秒来衡量。图形的顶部就是延迟的分布。这是有竟争的测试，使用四个线程执行该程序。 这个测

13、试是在8核的mbp i7上运行的。 每次测试迭代200,000,000次，并冇10,000次预热。根据吞吐率为每微妙迭代一次来调整遗漏。sync/lock50909999.999.9999.99999.9999 worstno contentiosync0.060.0780.0820.150.3344886,680lock0.060.0820.0820.150.3040802,820contentionsync0.160.417.627485413,47014,940lock0.070.161527442502,16014,940如我们所期望的一样，没有竞争时，结果是基本相同的。jit已经对l

14、ock和 synchronized进行了优化。在有竞争的情况下，占用百分比低的吋候，使用lock 会稍微快一点，但是这种差别真的很小。所以，即使存在很多的年青代gc (minorgc）,它们也没冇显著的降低lock效率。如果都是轻量级的lock,总体上就 比较快了。这是调整为有遗漏情况后的结果。sync/lock50909999.999.9999.999 99.9999 worstno contentio sync| 0,0910.13 4821,500 57,670 73,400 73,40073,400lock0.090.13 4213,370 59,770 66,060 69,21069

15、,210contentionsync0.280.44 3,470 59,770 85,980 102,760 102,760 106,950lock1.354 14,42 42,990 94,370 106,950 111,150 111,150当然，在冇遗漏的情况下延迟会更高。再次可以看到，在无竞争情况下，lock和synchronized的性能是相同这就没什么很惊奇了。在竞争条件下,百分率为99%时,我们看到synchronized比lock表现好10x。 在这之后，两者的表现基木是一致的。我猜测这是因为gc回收的效率导致lock比synchronised要慢，大概每 300-1200微妙发生一次gc回收。尤其是到达99%z后，慢得就