think in java 浅谈 SerialNumberChecker+ SimpleMicroBenchmark+SynchronizationComparisons

本文主要是介绍think in java 浅谈 SerialNumberChecker+ SimpleMicroBenchmark+SynchronizationComparisons,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

think in java 浅谈 SerialNumberChecker+ SimpleMicroBenchmark+SynchronizationComparisons

11 SerialNumberChecker

  • 添加 synchronized 有效保证了线程安全
    • volatile not means thread safe
    • 有效后,就找不到重复的元素,程序进行循环,记得手动关闭

附核心的修改代码

public  static int nextSerialNumber() { //here modifyreturn serialNumber++; // Not thread-safe //    private static volatile int serialNumber = 0;}

12 实战 SimpleMicroBenchmark

先秀出结果

//本机结果
synchronized:  298930769
Lock:          251456214
Lock/synchronized = 0.841
//教材结果
/* Output: (75% match)
synchronized:  244919117
Lock:          939098964
Lock/synchronized = 3.834
*/
  • 结果和教材代码竟然不符合,教材上说75%情况下 Lock慢,但是我是隐形加锁的慢,并且二者在多次实验里差距不大了
  • TODO: 留待后续研究,建议减少数据量来测试

13 有意思的实战 SynchronizationComparisons

13.1 我的浅识

这里的结果输出
肯定是baseline最快。
次之是比较synchronized /Lock/Atomic的系统延迟

  • 原生代码运行的不是顺利
    分别对Baseline/Atomic 修改了回绕的边界,才完整跑过5轮测试

  • 大的数据量读/写环境下,synchronized 没有优势。在简单的生产者/消费者案例里面,
    在简单的生产者/消费者案例里面,趋势和教材一致。
    在我的电脑上(i5+4G Ram+ssd),跌倒到第二轮(100000),synchronized完全就落后于lock/atomic变量。
    以常见的 synchronized/ Lock 的测试为例,lock领先的优势始终保持在1.3x以下,没有出现源代码示范输出的大数据量的巨大落差(高达65倍)
    我想,某种情形下,大数据量,synchronized可以代替lock ??
    不过肯定的是,小数据量,synchronized比Lock看起来更简单 ,更快。

    待确定的是,要确定时间的消耗的主体,要确认时间的延迟是来自于锁。

  • Atomic的不适合性
    首先看原生代码的注释

        // Oops! Relying on more than one Atomic at// a time doesn't work. But it still gives us// a performance indicator:
同一地方使用不止一个原子类,无法正常工作。
  • 果然atomic的使用有局限性

13.2 作者原文结论解读

This program uses the Template Method design pattern24 to put all the common code in the

base class and isolate all the varying code in the derived class implementations of
accumulate( ) and read( ). In each of the derived classes SynchronizedTest, LockTest,
and AtomicTest, you can see how accumulate( ) and read( ) express different ways of
implementing mutual exclusion.

    模板 设计模式
In this program, tasks are executed via a FixedThreadPool in an attempt to keep all the

thread creation at the beginning, and prevent any extra cost during the tests. Just to make
sure, the initial test is duplicated and the first result is discarded because it includes the
initial thread creation.

    使用线程池,不计入线程创建的开销并且,第一次使用线程的时候,有一个热身的线程哈!

A CyclicBarrier is necessary because we want to make sure all the tasks have completed
before declaring each test complete.

    同步器CyclicBarrier,保证测试完之前运行完

A static clause is used to pre-load the array of random numbers, before any tests begin. This
way, if there is any overhead to generating random numbers, we won’t see it during the test.

Each time accumulate( ) is called, it moves to the next place in the array preLoaded
(wrapping to the beginning of the array) and adds another randomly generated number to
value. The multiple Modifier and Reader tasks provide contention on the Accumulator
object.

Notice that in AtomicTest, I observe that the situation is too complex to try to use Atomic
objects—basically, if more than one Atomic object is involved, you will probably be forced to
give up and use more conventional mutexes (the JDK documentation specifically states that
using Atomic objects only works when the critical updates for an object are confined to a
single variable). However, the test is left in place so that you can still get a feel for the
performance benefit of Atomic objects.

多个Atomic对象 不适合这里的应用,详细参考jdk说明

In main( ), the test is run repeatedly and you can decide to ask for more than five repetitions
(the default). For each repetition, the number of test cycles is doubled, so you can see how
the different mutexes behave when running for longer and longer times. As you can see from
the output, the results are rather surprising. For the first four iterations, the synchronized
keyword seems to be more efficient than using a Lock or an Atomic. But suddenly, a
threshold is crossed and synchronized seems to become quite inefficient, while Lock and
Atomic seem to roughly maintain their proportion to the BaseLine test, and therefore
become much more efficient than synchronized.

    锁的趋势

Keep in mind that this program only gives an indication of the differences between the
various mutex approaches, and the output above only indicates these differences on my
particular machine under my particular circumstances. As you can see if you experiment with
it, there can be significant shifts in behavior when different numbers of threads are used and
when the program is run for longer periods of time. Some hotspot runtime optimizations are
not invoked until a program has been running for several minutes, and in the case of server
programs, several hours.

其他考量因素:机器运行时的配置因素 | 影响gc的因素|jvm优化的因素等

That said, it is fairly clear that using Lock is usually significantly more efficient than using
synchronized, and it also appears that the overhead of synchronized varies widely, while
Locks are relatively consistent.

本节重点:syschronized不稳定,而lock更稳定。

Does this mean you should never use the synchronized keyword? There are two factors to
consider: First, in SynchronizationComparisons.java, the bodies of the mutexed
methods are extremely small. In general, this is a good practice—only mutex the sections that
you absolutely must. However, in practice the mutexed sections may be larger than those in
the above example, and so the percentage of time in the body will probably be significantly
bigger than the overhead of entering and exiting the mutex, and could overwhelm any benefit
of speeding up the mutex. Of course, the only way to know is— when you’re tuning for
performance, no sooner—to try the different approaches and see what impact they have.
Second, it’s clear from reading the code in this chapter that the synchronized keyword
produces much more readable code than the lock try/finally-unlock idiom that Locks
require, and that’s why this chapter primarily uses the synchronized keyword. As I’ve
stated elsewhere in this book, code is read much more than it is written—when
programming, it is more important to communicate with other humans than it is to
communicate with the computer—and so readability of code is critical. As a result, it makes
sense to start with the synchronized keyword and only change to Lock objects when you
are tuning for performance.

lock 和syschronize 的选择: 可读性 和 高效性的平衡

Finally, it’s nice when you can use the Atomic classes in your concurrent program, but be
aware that, as we saw in SynchronizationComparisons.java, Atomic objects are only
useful in very simple cases, generally when you only have one Atomic object that’s being
modified and when that object is independent from all other objects. It’s safer to start with
more traditional mutexing approaches and only attempt to change to Atomic later, if
performance requirements dictate

其他 好书推荐

dw的设计模式
thinking in patterns

这篇关于think in java 浅谈 SerialNumberChecker+ SimpleMicroBenchmark+SynchronizationComparisons的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/894380

相关文章

Spring Boot @RestControllerAdvice全局异常处理最佳实践

《SpringBoot@RestControllerAdvice全局异常处理最佳实践》本文详解SpringBoot中通过@RestControllerAdvice实现全局异常处理,强调代码复用、统... 目录前言一、为什么要使用全局异常处理?二、核心注解解析1. @RestControllerAdvice2

Spring IoC 容器的使用详解(最新整理)

《SpringIoC容器的使用详解(最新整理)》文章介绍了Spring框架中的应用分层思想与IoC容器原理,通过分层解耦业务逻辑、数据访问等模块,IoC容器利用@Component注解管理Bean... 目录1. 应用分层2. IoC 的介绍3. IoC 容器的使用3.1. bean 的存储3.2. 方法注

Spring事务传播机制最佳实践

《Spring事务传播机制最佳实践》Spring的事务传播机制为我们提供了优雅的解决方案,本文将带您深入理解这一机制,掌握不同场景下的最佳实践,感兴趣的朋友一起看看吧... 目录1. 什么是事务传播行为2. Spring支持的七种事务传播行为2.1 REQUIRED(默认)2.2 SUPPORTS2

怎样通过分析GC日志来定位Java进程的内存问题

《怎样通过分析GC日志来定位Java进程的内存问题》:本文主要介绍怎样通过分析GC日志来定位Java进程的内存问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、GC 日志基础配置1. 启用详细 GC 日志2. 不同收集器的日志格式二、关键指标与分析维度1.

Java进程异常故障定位及排查过程

《Java进程异常故障定位及排查过程》:本文主要介绍Java进程异常故障定位及排查过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、故障发现与初步判断1. 监控系统告警2. 日志初步分析二、核心排查工具与步骤1. 进程状态检查2. CPU 飙升问题3. 内存

java中新生代和老生代的关系说明

《java中新生代和老生代的关系说明》:本文主要介绍java中新生代和老生代的关系说明,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、内存区域划分新生代老年代二、对象生命周期与晋升流程三、新生代与老年代的协作机制1. 跨代引用处理2. 动态年龄判定3. 空间分

Java设计模式---迭代器模式(Iterator)解读

《Java设计模式---迭代器模式(Iterator)解读》:本文主要介绍Java设计模式---迭代器模式(Iterator),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,... 目录1、迭代器(Iterator)1.1、结构1.2、常用方法1.3、本质1、解耦集合与遍历逻辑2、统一

Java内存分配与JVM参数详解(推荐)

《Java内存分配与JVM参数详解(推荐)》本文详解JVM内存结构与参数调整,涵盖堆分代、元空间、GC选择及优化策略,帮助开发者提升性能、避免内存泄漏,本文给大家介绍Java内存分配与JVM参数详解,... 目录引言JVM内存结构JVM参数概述堆内存分配年轻代与老年代调整堆内存大小调整年轻代与老年代比例元空

深度解析Java DTO(最新推荐)

《深度解析JavaDTO(最新推荐)》DTO(DataTransferObject)是一种用于在不同层(如Controller层、Service层)之间传输数据的对象设计模式,其核心目的是封装数据,... 目录一、什么是DTO?DTO的核心特点:二、为什么需要DTO?(对比Entity)三、实际应用场景解析

Java 线程安全与 volatile与单例模式问题及解决方案

《Java线程安全与volatile与单例模式问题及解决方案》文章主要讲解线程安全问题的五个成因(调度随机、变量修改、非原子操作、内存可见性、指令重排序)及解决方案,强调使用volatile关键字... 目录什么是线程安全线程安全问题的产生与解决方案线程的调度是随机的多个线程对同一个变量进行修改线程的修改操