温馨提示×

温馨提示×

您好,登录后才能下订单哦!

密码登录×
登录注册×
其他方式登录
点击 登录注册 即表示同意《亿速云用户服务条款》

Java中延时Lock vs Synchronized的实例分析

发布时间:2021-11-09 17:29:09 来源:亿速云 阅读:176 作者:柒染 栏目:编程语言

本篇文章给大家分享的是有关Java中延时Lock vs Synchronized的实例分析,小编觉得挺实用的,因此分享给大家学习,希望大家阅读完这篇文章后可以有所收获,话不多说,跟着小编一起来看看吧。

几天前,当我诊断一些 JIT 编译期间奇怪的分配问题时,发现  java.util.concurrent.locks.ReentrantLock  的分配有问题,不过这只在竞争条件下出现。(这一点很容易证明,只要运行一个在 Lock 上建立竞争并指定 –verbosegc  参数测试程序(类似下面的程序))。

示例是在有 Lock 竞争时 GC 的输出结果:

[GC (Allocation Failure) 16384K->1400K(62976K), 0.0016854 secs] [GC (Allocation Failure) 17784K->1072K(62976K), 0.0011939 secs] [GC (Allocation Failure) 17456K->1040K(62976K), 0.0008452 secs] [GC (Allocation Failure) 17424K->1104K(62976K), 0.0008338 secs] [GC (Allocation Failure) 17488K->1056K(61952K), 0.0008799 secs] [GC (Allocation Failure) 17440K->1024K(61952K), 0.0010529 secs] [GC (Allocation Failure) 17408K->1161K(61952K), 0.0012381 secs] [GC (Allocation Failure) 17545K->1097K(61440K), 0.0004592 secs] [GC (Allocation Failure) 16969K->1129K(61952K), 0.0004500 secs]  [GC (Allocation Failure) 17001K->1129K(61952K), 0.0003857 secs]

我怀疑是否是在垃圾回收时必须对清理 Lock 上分配的空间,在高度竞争的环境下,将会选择一种比内建的 ‘synchronized‘ 更坏的同步策略。

当然,这个问题比其他任何问题都更加学术。如果你确实非常关心延迟,你会发现自己从来不会(或者绝不应该)有这样一种情况会需要这么多的线程锁。不过,请继续跟我一起探究这个问题,因为这个过程和结果都非常有趣。

简史:锁是2004年,在Java 1.5中引入的。由于对简单并发结构的迫切需要,锁以及其他并发工具因此而诞生。在这之前,你不得不通过内建的 synchronized 和 Object 的 wait()、notify() 方法来控制并发。

ReentrantLock 提供许多比 synchronized 更好的功能,下面是一些例子:

  • 变得非结构化——比如,不会受块或方法的限制,允许你跨多个方法持有锁。

  • 轮询锁

  • 等待锁超时

  • 配置失败策略

但是它们在延迟测试中有什么作用呢?

我写了一个简单的测试来比较 Lock 和 synchronized 的性能。

这段代码允许改变线程的数量(1个线程意味着不存在竞争)及竞争的数量。通过有遗漏(coordinated omission)和没有遗漏来衡量。
采用 Lock 或者 synchronised 来运行测试。

为了记录结果,我使用了 Histogram 类。该类是 Peter Lawrey 创建的。你可以在 Chronicle-Core 的工具类中找到该类。

import org.junit.Test;  import java.util.concurrent.locks.Lock; import java.util.concurrent.locks.ReentrantLock;  public class LockVsSync {     private static final boolean COORDINATED_OMISSION = Boolean.getBoolean("coordinatedOmission");     //Either run testing Lock or testing synchronized     private static final boolean IS_LOCK = Boolean.getBoolean("isLock");     private static final int NUM_THREADS = Integer.getInteger("numThreads");      <a href='http://www.jobbole.com/members/madao'>@Test</a>     public void test() throws InterruptedException {         Lock lock = new ReentrantLock();         for (int t = 0; t &lt; NUM_THREADS; t++) {             if (t == 0) {                 //Set the first thread as the master which will be measured                 //设置***个线程作为测量的线程                 //The other threads are only to cause contention                 //其他线程只是引起竞争                 Runner r = new Runner(lock, true);                 r.start();             } else {                 Runner r = new Runner(lock, false);                 r.start();             }         }          synchronized(this){             //Hold the main thread from completing             wait();         }      }      private void testLock(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 {         private 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 Histogram();              long rate = 1000;//expect 1 every microsecond             long now =0;             for (int i = -10000; i 0){                     if(!COORDINATED_OMISSION) {                         now += rate;                         while(System.nanoTime() =0 &amp;&amp; master){                     histogram.sample(System.nanoTime() - now);                 }             }             if (master) {                 System.out.println(histogram.toMicrosFormat());                 System.exit(0);             }         }     } }

结果如下:

这是没有遗漏(co-ordinated omission)的结果:

  • 采用微秒来衡量。

  • 图形的顶部就是延迟的分布。

  • 这是有竞争的测试,使用四个线程执行该程序。

  • 这个测试是在8核的 MBP i7 上运行的。

  • 每次测试迭代200,000,000次,并有10,000次预热。

  • 根据吞吐率为每微妙迭代一次来调整遗漏。

Java中延时Lock vs Synchronized的实例分析

如我们所期望的一样,没有竞争时,结果是基本相同的。JIT 已经对 Lock 和 synchronized  进行了优化。在有竞争的情况下,占用百分比低的时候,使用 Lock 会稍微快一点,但是这种差别真的很小。所以,即使存在很多的年青代GC(minor  GC),它们也没有显著的降低 Lock 效率。如果都是轻量级的 Lock,总体上就比较快了。

这是调整为有遗漏情况后的结果。

Java中延时Lock vs Synchronized的实例分析

当然,在有遗漏的情况下延迟会更高。

再次可以看到,在无竞争情况下,lock 和 synchronized 的性能是相同&mdash;&mdash;这就没什么很惊奇了。

在竞争条件下,百分率为99%时,我们看到 synchronized 比 lock 表现好10X。在这之后,两者的表现基本是一致的。

我猜测这是因为GC回收的效率导致 lock 比 synchronised  要慢,大概每300-1200微妙发生一次GC回收。尤其是到达99%之后,慢得就相当明显了。在这个之后,延迟率可能与硬件和操作系统(OS)相关。但 是,这只是我个人的推断,没有做更深入的调查。

以上就是Java中延时Lock vs Synchronized的实例分析,小编相信有部分知识点可能是我们日常工作会见到或用到的。希望你能通过这篇文章学到更多知识。更多详情敬请关注亿速云行业资讯频道。

向AI问一下细节

免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。

AI