东莞高端网站建设费,婚礼礼服网站界面设计,自己做文学网站赚钱吗,王烨诡异复苏的漫画叫什么mac 大写锁定延迟特别是在这篇文章中#xff0c;我们将讨论#xff1a; java.concurrent.Lock创建的垃圾 比较锁与同步 如何以编程方式测量延迟 争用对锁和同步的影响 遗漏对延迟测试的影响 回到我最喜欢的主题之一#xff0c;垃圾创建/分配。 有关此主题的更多详细信… mac 大写锁定延迟 特别是在这篇文章中我们将讨论 java.concurrent.Lock创建的垃圾 比较锁与同步 如何以编程方式测量延迟 争用对锁和同步的影响 遗漏对延迟测试的影响 回到我最喜欢的主题之一垃圾创建/分配。 有关此主题的更多详细信息请参见我以前的文章例如性能优化 的第一条规则和重新访问 性能优化 的第一条规则逃逸分析的效果 。 特别是为什么分配是理解性能问题的如此关键因素。 几天前我在尝试诊断JIT编译过程中分配的一些奇怪影响时遇到了什么这是java.util.concurrent.locks.ReentrantLock分配的但仅当处于竞争状态时才分配。 这可以通过运行一个测试程序如下面的程序很容易地证明该程序使用– 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] 我想知道清理这些分配所必需的垃圾回收是否意味着在高度竞争的环境中与使用内置的“ synchronized ”相比 Lock在同步方面是更糟糕的选择。 当然这个问题比其他任何事情都更具学术性。 如果您确实非常关心延迟那么您将永远或者肯定永远不会陷入需要大量线程锁定的情况。 不过因为过程和结果很有趣所以请和我在一起。 有点历史。 2004年Java 1.5中引入了Lock 。为了简化并发构造迫切需要将Lock与其他并发实用程序一起使用。 到目前为止您已经处理了Object上的内置synchronized和wait()notify() 。 ReentrantLock除了提供synchronized功能外还提供许多功能 这仅仅是列举的一小部分 非结构化–即您不限于在块或方法中使用它。 它使您可以通过几种方法持有锁。 锁定轮询 超时等待锁 可配置的公平政策 但是它们如何进行延迟测试呢 我在下面编写了一个简单的测试比较了锁与同步的性能。 该代码使您可以更改线程数1个线程表示没有争用从而调整争用量。 在有或没有协同遗漏的情况下进行测量请参阅以前的博客《协调遗漏的效果》 运行测试锁定或同步测试。 要记录我的结果您会注意到我使用了Histogram类。 这是由彼得·劳瑞Peter Lawrey创建的。 你可以找到类为纪事核心在实用这里 。 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 synchronizedprivate static final boolean IS_LOCK Boolean.getBoolean(isLock);private static final int NUM_THREADS Integer.getInteger(numThreads);Testpublic void test() throws InterruptedException {Lock lock new ReentrantLock();for (int t 0; t NUM_THREADS; t) {if (t 0) {//Set the first thread as the master which will be measured//The other threads are only to cause contentionRunner r new Runner(lock, true);r.start();} else {Runner r new Runner(lock, false);r.start();}}synchronized(this){//Hold the main thread from completingwait();}}private void testLock(Lock rlock) {rlock.lock();try {for (int i 0; i 2; i) {double x 10 / 4.5 i;}} finally {rlock.unlock();}}private synchronized void testSync() {for (int i 0; i 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;}Overridepublic void run() {Histogram histogram null;if (master)histogram new Histogram();long rate 1000;//expect 1 every microsecondlong now 0;for (int i -10000; i 200_000_000; i) {if(i0){now System.nanoTime();} else if(i0){if(!COORDINATED_OMISSION) {now rate;while(System.nanoTime() now);}elsenow System.nanoTime();}if(IS_LOCK)testLock(lock);elsetestSync();if(i0 master){histogram.sample(System.nanoTime() - now);}}if (master) {System.out.println(histogram.toMicrosFormat());System.exit(0);}}}
} 结果如下 这些是忽略了遗漏的结果 时间以微秒为单位。 延迟分布在图的顶部。 该测试中的争用意味着要使用4个线程运行该程序。 测试是在具有8个逻辑CPU的MBP i7上运行的。 每个测试包括200,000,000次迭代和10,000次迭代预热。 调整协调遗漏时的吞吐量为1迭代/微秒。 正如预期的那样在没有争用的情况下结果几乎相同。 JIT将优化锁定并进行同步。 在较低的百分位数中使用Lock进行争用要快一些但实际上并没有太多。 因此即使有许多较小的垃圾回收它们似乎也没有显着降低锁的速度。 如果有的话锁定总体上会稍微快一点。 这些是为协调省略而调整的结果。 这些数字当然更高因为它们允许引起真正的延迟。 同样锁和同步也没有争用它们的作用相同–在那里没有很大的惊喜。 通过争用直到第99个百分位我们现在看到的同步锁定性能提高了10倍。 之后时间几乎相同。 我可以推测与同步相比gc集合的影响介于300-1200微秒之间是导致锁缓慢的原因。 尤其是因为速度下降仅出现到第99个百分位时才可见-在此之后延迟可能会降到硬件和操作系统上。 但是这只是我的推测无需进一步调查。 结论 这篇文章的收获更多是关于衡量和分析延迟的过程。 有趣的是 Lock在竞争时进行分配但在现实世界中不太可能产生任何实际变化 翻译自: https://www.javacodegeeks.com/2015/08/a-case-study-in-analysing-latency-lock-vs-synchronized.htmlmac 大写锁定延迟
