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