atomic

前言 只有光头才能变强。 文本已收录至我的GitHub精选文章，欢迎Star ： https://github.com/ZhongFuCheng3y/3y 在上周总结了一篇「工作中常用到的Java集合类」，反响还不错。这周来写写Java另一个重要的知识点：「 多线程 」 多线程大家在初学的时候，对这个知识点应该有不少的疑惑的。我认为主要原因有两个： 多线程在初学的时候不太好学，并且一般写项目的时候也很少用得上（至少在初学阶段时写的项目基本不需要自己创建线程）。 多线程的知识点在面试经常考，多线程所涉及的知识点非常多，难度也不低。 这就会给人带来一种感觉「 这破玩意涉及的东西是真的广，平时也不怎么用，怎么面试就偏偏爱问这个鬼东西 」 不多BB，我要开始了。 为什么使用多线程？ 首先，我们要明确的是「为什么要使用多线程」，可能有人会认为「 使用多线程就是为了加快程序运行的速度啊 」。如果你是这样回答了，那面试官可能会问你「那多线程是怎么加快程序运行速度的？」 于我的理解：使用多线程最主要的原因是 提高系统的资源利用率 。 现在CPU基本都是多核的，如果你只用单线程，那就是只用到了一个核心，其他的核心就相当于空闲在那里了。 厕所的坑位有5个，如果只用一个坑位，那不是很亏？比如现在我有5个人要上厕所。 在单线程的时候：进去一个人解决要10分钟，然后后面的人都得等一个坑位

atomic和nonatomic用来决定编译器生成的getter和setter是否为原子操作。 atomic 设置成员变量的@property属性时，默认为atomic，提供多线程安全。 在多线程环境下，原子操作是必要的，否则有可能引起错误的结果。加了atomic，setter函数会变成下面这样： {lock} if (property != newValue) { [property release]; property = [newValue retain]; } {unlock} 禁止多线程，变量保护，提高性能。 atomic是Objc使用的一种线程保护技术，基本上来讲，是防止在写未完成的时候被另外一个线程读取，造成数据错误。而这种机制是耗费系统资源的，所以在iPhone这种小型设备上，如果没有使用多线程间的通讯编程，那么nonatomic是一个非常好的选择。 指出访问器不是原子操作，而默认地，访问器是原子操作。这也就是说，在多线程环境下，解析的访问器提供一个对属性的安全访问，从获取器得到的返回值或者通过设置器设置的值可以一次完成，即便是别的线程也正在对其进行访问。如果你不指定 nonatomic ，在自己管理内存的环境中，解析的访问器保留并自动释放返回的值，如果指定了 nonatomic ，那么访问器只是简单地返回这个值。 来源： oschina 链接： https:/

背景 Read the fucking source code! --By 鲁迅 A picture is worth a thousand words. --By 高尔基 说明： Kernel版本：4.14 ARM64处理器，Contex-A53，双核 使用工具：Source Insight 3.5， Visio 1. 概述 吹起并发机制研究的进攻号角了！ 作为第一篇文章，应该提纲挈领的介绍下并发。 什么是并发，并发就是：你有两个儿子，同时抢一个玩具玩，你一巴掌打在你大儿子手上，小儿子拿到了玩具。 并发是指多个执行流访问同一个资源，并发引起竞态。 来张图吧： 图中每一种颜色代表一种竞态情况，主要归结为三类： 进程与进程之间：单核上的抢占，多核上的SMP； 进程与中断之间：中断又包含了上半部与下半部，中断总是能打断进程的执行流； 中断与中断之间：外设的中断可以路由到不同的CPU上，它们之间也可能带来竞态； 目前内核中提供了很多机制来处理并发问题， spinlock 就是其中一种。 spinlock ，就是大家熟知的自旋锁，它的特点是自旋锁保护的区域不允许睡眠，可以用在中断上下文中。自旋锁获取不到时，CPU会忙等待，并循环测试等待条件。自旋锁一般用于保护很短的临界区。 下文将进一步揭开神秘的面纱。 2. spinlock原理分析 2.1 spin_lock/spin_unlock

1. 理解原子操作 1. 实现一个简单的测试用例 public class Counter { volatile int i = 0; public void add() { i++; } } public class Demo1_CounterTest { public static void main(String[] args) throws InterruptedException { final Counter ct = new Counter(); for (int i = 0; i < 6; i++) { new Thread(() -> { for (int j = 0; j < 10000; j++) { ct.add(); } System.out.println("done..."); }).start(); } Thread.sleep(6000L); System.out.println(ct.i); } } 2. 结果分析 最终的结果是小于等于60000。 原因： i++ 并不是一个原子操作。 反编译 Counter 类，部分结果如下： 针对操作进行了切分： 3. 原子操作描述 原子操作可以是一个步骤，也可以是多个步骤，但是其顺序不可以被打乱，也不可以被切割而只执行其中的一部分（不可中断性）。 将整个操作是做一个整体，资源在该次操作中保持一致

问题： What do atomic and nonatomic mean in property declarations? 属性声明中 atomic 和 nonatomic 是什么意思？ @property(nonatomic, retain) UITextField *userName; @property(atomic, retain) UITextField *userName; @property(retain) UITextField *userName; What is the operational difference between these three? 这三个之间的操作区别是什么？ 解决方案： 参考一： https://stackoom.com/question/2TBq/原子属性和非原子属性有什么区别 参考二： https://oldbug.net/q/2TBq/What-s-the-difference-between-the-atomic-and-nonatomic-attributes 来源： oschina 链接： https://my.oschina.net/u/3797416/blog/3214621

3 月，跳不动了？>>> 概述 在多线程应用中有个很典型的业务就是共同争抢一个某一个资源，比如很典型的秒杀，很多的线程在争夺某一个资源。本文以一个最简单的例子说明，2万个线程一起争夺一个变量+1的操作。 只使用atomic 在https://my.oschina.net/u/3707404/blog/3211668中，使用atomic类型可以避免多线程加锁导致的效率问题，同时保持资源安装，但是atomic本身有也其缺陷，其不能保证访问的一致性，即当100个线程都执行+1他能保证每一个线程的操作都会成功，但是如果你访问这个变量，其不保证每一个线程都看到的是最新的值，通过下面简单的代码你就会体会到。 #include <vector> #include <queue> #include <iostream> #include <boost/thread.hpp> #include <chrono> class Task { public : std :: atomic < int > queue ; boost :: mutex mutex ; Task () { queue = 0 ; } void get() { if ( queue == 0 ) { usleep( 1 ); queue ++ ; } } }; int main( int argc, char **argv) {

3 月，跳不动了？>>> 目录 1. 前言 2 2. 结论 2 3. volatile 应用场景 3 4. 内存屏障（ Memory Barrier ） 4 5. setjmp 和 longjmp 4 1) 结果 1 （非优化编译： g++ -g -o x x.cpp -O0 ） 5 2) 结果 2 （优化编译： g++ -g -o x x.cpp -O2 ） 6 6. 不同 CPU 架构的一致性模型 6 7. x86-TSO 7 8. C++ 标准库对内存顺的支持 7 1) 头文件 <stdatomic.h> 7 2) 头文件 <atomic> 8 附 1 ： CPU 、缓存和主存 8 第三级缓存（ L3 Cache ）多核共享： 8 附 2 ： SMP 对称多处理器结构 9 附 3 ：在线 C++ 编译器 9 附 4 ：资源链接 10 1) C++ 标准委员会（ The C++ Standards Committee ） 10 2) 标准 C++ 基金会 10 3) C++ 之父 10 4) Linux 内核关于 volatile 的说明 10 5) Intel 内存模型（ Intel Memory Model ） 10 6) Intel TSO 内存模型 10 7) Sequential Consistency &TSO 10 8) Write buffer 10 9)

3 月，跳不动了？>>> Zab 把节点分两种，Leader（主）和Follower（从）。 有一个主节点，所有写操作全部通过节点进行处理，如果一个从节点收到了一个写操作请求，就会转给主节点处理。 其他节点都是从节点，可以通过从节点进行读操作。 主节点通过选举得出，主节点失踪后，其他从节点自动开始选举新的主节点。 使用 Zookeeper 参考 Architecture of ZAB – ZooKeeper Atomic Broadcast protocol Raft Raft将一致性的问题分解为了三个问题： Leader Election：在Leader故障的时候，选出一个新的Leader。 Log Replication：Leader需要让日志完整地复制到集群内的所有服务器 Safety：如果某个服务器在特定的index提交了一个日志，那么不能有其它的服务器在相同的index提交日志，同一时刻只能保证有一个Leader。 发现主节点失踪一段时间后，向所有从节点向其他从节点发消息，让他们选自己为新的主节点； 还没参加选举的节点如果收到其他节点的选举请求，就选举自己收到的第一个节点，后面谁再请求自己支持选举，就告诉他们我已经支持另一个节点了 如果一个节点发现另一个节点得到的支持比自己多，也就开始无条件支持那个节点选举，同时让支持自己的节点也去支持它