55 | 理解Disruptor（下）：不需要换挡和踩刹车的CPU，有多快？

ReentrantLock内部不也是CAS实现的吗

课后问题： 对比了Sequence与AtomicLong源码，在于CAS之前，Disruptor直接取原有值，做CAS操作；而AtomicLong使用了getLongVolatile获值。 两者value都用了Volatile来修饰，这点是共同的；但在于获值时，AtomicLong又再次使用volatile(getLongVolatile), 由于Volatile会在内存中强行刷新此值，相比这样就会增加一次性能的消耗，另外还有Spinlock（自旋锁），这两点都会带来性能消耗。 为什么Disruptor可以这样做，免掉getLongVolatile操作，我猜想应该是缓存行的填充，避免了伪共享（False Sharing）的问题，线程对value值的修改，不会出现不同线程同时修改同一缓存行不同变量的问题，所以不需要再次强行刷内存的步骤。 请老师指正！！！ /** Sequence关于取值是直接Get(), 查看内部方法直接返回value * * Atomically add the supplied value. * * @param increment The value to add to the sequence. * @return The value after the increment. */ public long addAndGet(final long increment) { long currentValue; long newValue; do { currentValue = get(); newValue = currentValue + increment; } while (!compareAndSet(currentValue, newValue)); return newValue; } /** AtomicLong关于取值时使用getLongVolatile，查看其源码，增加了Volatile和自旋锁 * * getAndAddLong * */ public final long getAndAddLong(Object var1, long var2, long var4) { long var6; do { var6 = this.getLongVolatile(var1, var2); } while(!this.compareAndSwapLong(var1, var2, var6, var6 + var4)); return var6; } /** getLongVolatile源码（C++） * * 1. volatile, 刷新内存 * 2.Spinlock, 自旋锁 */ jlong sun::misc::Unsafe::getLongVolatile (jobject obj, jlong offset) { volatile jlong *addr = (jlong *) ((char *) obj + offset); spinlock lock; return *addr; }

极客时间买了13个专栏，终于完成了一个专栏的所有笔记 专栏所有笔记如下：https://www.cnblogs.com/luoahong/p/10496701.html

专栏最开始就订阅了，看到了这篇专栏目录中的这篇文档标题，当时就想着要从底层了解disruptor的原理，也一篇一篇认真的跟了下来，不知不觉就到了今天，虽然有很多后续还是要回去时常翻阅的知识点，但是也庆幸自己能一路跟着老师到现在。 课后思考题会去翻源码再回来补充

看了下jdk 1.8的 AtomicLong 和disruptor的sequence， 个人认为有两点不同： 1. disruptor 加了上一讲里面的padding, 以进一步利用缓存。 2. Atomiclong 里面提供了更多的方法，并且判断cpu是否支持无锁cas 相同点，底层都是调用unsafe类实现硬件层面的操作，以跳过jdk的限制。

LinkedBlockingQueue源码（JDK1.8）看了一下, 使用的是ReentrantLock和Condition来控制的，没发现老师说的synchronized关键字, 是不是哪里我忽略掉了？

Cas仍然会涉及到内存读取，老师能否介绍下rcu锁？

学习中一步步跟进：越来越明白其实真正弄明白为何学习的中间层其实是操作系统和计算机原理；就像老师的课程中不少就和操作系统相关，而在此基础上可以衍生出一系列相关的知识。 就像老师的2个TOP：存储与IO系统，应用篇分别就是一个向下一个向上；代码题对于不做纯代码超过5年的来说有点难，跟课再去学Java有点难且时间实在不够-毕竟运维的coding能力都偏差，不过大致能明白原理，从原理层去解释一些问题的根源原因，以及某些场合下那些可能更加适用。 其实通过操作系统和组成原理会衍生出很多知识：选择合适的方向专攻确实不错。向老师提个小的要求：希望在最后一堂课可以分享老师在做这个专栏所查阅的主要书籍，毕竟没人可以学完一遍就基本掌握的；老师所看的核心资料是我们后续再看课程提升自己的一个辅助手段吧。

ReentrantLock内部也有CAS的操作，只不过也会有Lock的操作。Disruptor直接使用CAS，是简化了操作。

文章中加锁和不加锁性能比较的case老师的数据是差了50倍，我在intel E5 v4和鲲鹏920下跑出来都是查了80倍。 不过其中的原因不是因为加锁，而是lock.lock() 函数自身包含了几十条指令，而++只有简单的几个指令，也就是两者指令数就差了1个数量级。 例子中不加锁性能好的另外一个原因是 ++指令 对流水线十分友好，基本能跑满流水线（IPC 跑到4)；而lock()那堆指令只能把IPC跑到0.5-0.8之间。 在只有一个线程的情况下加锁中的"锁"对性能是没有任何影响的，比如假设你的业务逻辑几万个指令，加上lock()多出来的几十个指令基本，基本是没有啥影响的。只有一个线程不会真正发生切换、等锁的糟心操作。只需要考虑实际指令量和对pipeline的友好程度