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

相关文章

java使用protobuf-maven-plugin的插件编译proto文件详解

《java使用protobuf-maven-plugin的插件编译proto文件详解》:本文主要介绍java使用protobuf-maven-plugin的插件编译proto文件,具有很好的参考价... 目录protobuf文件作为数据传输和存储的协议主要介绍在Java使用maven编译proto文件的插件

Java中的数组与集合基本用法详解

《Java中的数组与集合基本用法详解》本文介绍了Java数组和集合框架的基础知识,数组部分涵盖了一维、二维及多维数组的声明、初始化、访问与遍历方法,以及Arrays类的常用操作,对Java数组与集合相... 目录一、Java数组基础1.1 数组结构概述1.2 一维数组1.2.1 声明与初始化1.2.2 访问

Javaee多线程之进程和线程之间的区别和联系(最新整理)

《Javaee多线程之进程和线程之间的区别和联系(最新整理)》进程是资源分配单位,线程是调度执行单位,共享资源更高效,创建线程五种方式:继承Thread、Runnable接口、匿名类、lambda,r... 目录进程和线程进程线程进程和线程的区别创建线程的五种写法继承Thread,重写run实现Runnab

Java 方法重载Overload常见误区及注意事项

《Java方法重载Overload常见误区及注意事项》Java方法重载允许同一类中同名方法通过参数类型、数量、顺序差异实现功能扩展,提升代码灵活性,核心条件为参数列表不同,不涉及返回类型、访问修饰符... 目录Java 方法重载(Overload)详解一、方法重载的核心条件二、构成方法重载的具体情况三、不构

Java通过驱动包(jar包)连接MySQL数据库的步骤总结及验证方式

《Java通过驱动包(jar包)连接MySQL数据库的步骤总结及验证方式》本文详细介绍如何使用Java通过JDBC连接MySQL数据库,包括下载驱动、配置Eclipse环境、检测数据库连接等关键步骤,... 目录一、下载驱动包二、放jar包三、检测数据库连接JavaJava 如何使用 JDBC 连接 mys

SpringBoot线程池配置使用示例详解

《SpringBoot线程池配置使用示例详解》SpringBoot集成@Async注解,支持线程池参数配置(核心数、队列容量、拒绝策略等)及生命周期管理,结合监控与任务装饰器,提升异步处理效率与系统... 目录一、核心特性二、添加依赖三、参数详解四、配置线程池五、应用实践代码说明拒绝策略(Rejected

一文详解SpringBoot中控制器的动态注册与卸载

《一文详解SpringBoot中控制器的动态注册与卸载》在项目开发中,通过动态注册和卸载控制器功能,可以根据业务场景和项目需要实现功能的动态增加、删除,提高系统的灵活性和可扩展性,下面我们就来看看Sp... 目录项目结构1. 创建 Spring Boot 启动类2. 创建一个测试控制器3. 创建动态控制器注

Java操作Word文档的全面指南

《Java操作Word文档的全面指南》在Java开发中,操作Word文档是常见的业务需求,广泛应用于合同生成、报表输出、通知发布、法律文书生成、病历模板填写等场景,本文将全面介绍Java操作Word文... 目录简介段落页头与页脚页码表格图片批注文本框目录图表简介Word编程最重要的类是org.apach

Spring Boot中WebSocket常用使用方法详解

《SpringBoot中WebSocket常用使用方法详解》本文从WebSocket的基础概念出发,详细介绍了SpringBoot集成WebSocket的步骤,并重点讲解了常用的使用方法,包括简单消... 目录一、WebSocket基础概念1.1 什么是WebSocket1.2 WebSocket与HTTP

SpringBoot+Docker+Graylog 如何让错误自动报警

《SpringBoot+Docker+Graylog如何让错误自动报警》SpringBoot默认使用SLF4J与Logback,支持多日志级别和配置方式,可输出到控制台、文件及远程服务器,集成ELK... 目录01 Spring Boot 默认日志框架解析02 Spring Boot 日志级别详解03 Sp