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实现检查多个时间段是否有重合

《Java实现检查多个时间段是否有重合》这篇文章主要为大家详细介绍了如何使用Java实现检查多个时间段是否有重合,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录流程概述步骤详解China编程步骤1:定义时间段类步骤2:添加时间段步骤3:检查时间段是否有重合步骤4:输出结果示例代码结语作

Java中String字符串使用避坑指南

《Java中String字符串使用避坑指南》Java中的String字符串是我们日常编程中用得最多的类之一,看似简单的String使用,却隐藏着不少“坑”,如果不注意,可能会导致性能问题、意外的错误容... 目录8个避坑点如下:1. 字符串的不可变性:每次修改都创建新对象2. 使用 == 比较字符串,陷阱满

Java判断多个时间段是否重合的方法小结

《Java判断多个时间段是否重合的方法小结》这篇文章主要为大家详细介绍了Java中判断多个时间段是否重合的方法,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录判断多个时间段是否有间隔判断时间段集合是否与某时间段重合判断多个时间段是否有间隔实体类内容public class D

IDEA编译报错“java: 常量字符串过长”的原因及解决方法

《IDEA编译报错“java:常量字符串过长”的原因及解决方法》今天在开发过程中,由于尝试将一个文件的Base64字符串设置为常量,结果导致IDEA编译的时候出现了如下报错java:常量字符串过长,... 目录一、问题描述二、问题原因2.1 理论角度2.2 源码角度三、解决方案解决方案①:StringBui

Java覆盖第三方jar包中的某一个类的实现方法

《Java覆盖第三方jar包中的某一个类的实现方法》在我们日常的开发中,经常需要使用第三方的jar包,有时候我们会发现第三方的jar包中的某一个类有问题,或者我们需要定制化修改其中的逻辑,那么应该如何... 目录一、需求描述二、示例描述三、操作步骤四、验证结果五、实现原理一、需求描述需求描述如下:需要在

Java中ArrayList和LinkedList有什么区别举例详解

《Java中ArrayList和LinkedList有什么区别举例详解》:本文主要介绍Java中ArrayList和LinkedList区别的相关资料,包括数据结构特性、核心操作性能、内存与GC影... 目录一、底层数据结构二、核心操作性能对比三、内存与 GC 影响四、扩容机制五、线程安全与并发方案六、工程

JavaScript中的reduce方法执行过程、使用场景及进阶用法

《JavaScript中的reduce方法执行过程、使用场景及进阶用法》:本文主要介绍JavaScript中的reduce方法执行过程、使用场景及进阶用法的相关资料,reduce是JavaScri... 目录1. 什么是reduce2. reduce语法2.1 语法2.2 参数说明3. reduce执行过程

如何使用Java实现请求deepseek

《如何使用Java实现请求deepseek》这篇文章主要为大家详细介绍了如何使用Java实现请求deepseek功能,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录1.deepseek的api创建2.Java实现请求deepseek2.1 pom文件2.2 json转化文件2.2

Java调用DeepSeek API的最佳实践及详细代码示例

《Java调用DeepSeekAPI的最佳实践及详细代码示例》:本文主要介绍如何使用Java调用DeepSeekAPI,包括获取API密钥、添加HTTP客户端依赖、创建HTTP请求、处理响应、... 目录1. 获取API密钥2. 添加HTTP客户端依赖3. 创建HTTP请求4. 处理响应5. 错误处理6.

Spring AI集成DeepSeek的详细步骤

《SpringAI集成DeepSeek的详细步骤》DeepSeek作为一款卓越的国产AI模型,越来越多的公司考虑在自己的应用中集成,对于Java应用来说,我们可以借助SpringAI集成DeepSe... 目录DeepSeek 介绍Spring AI 是什么?1、环境准备2、构建项目2.1、pom依赖2.2