年年开始，年年多线程。 无论你是什么程序员，都逃不过多线程并发的魔掌。 因为它从世界开始就存在了，它是现实世界在计算机中的概括。 所以，放松，不要害怕。背这一系列多线程的文章你几乎可以打败面试官了(真的不要...) 并发症，这是单核单线程机器上曾经不存在的(不是我不想，而是我做不到)。 如果把电脑看成一个木桶，那么CPU、内存、IO设施与我们Java开发者的关系最大。 到现在，这三种木板相互之间已经形成了很大的性能差异。 CPU的核心和线程数量越来越多，但内存的速度却跟不上CPU的步伐。同样，IO设施也跟不上内存的步伐。 因此，添加了缓存。经过科学论证，L3缓存是最可靠的，所以才有了常见的CPU L3缓存。 后来，前辈们对操作系统的各种调度级别进行了深入的优化，通过软硬兼施的技术，软硬件的完美结合，成就了今天互联网的繁荣。 我们只是这个城市的劳动人民。 言归正传，本文将解释并发世界中的“三宗罪”:可见性、原子性和有序性。 罪状一:可视性上一篇文章提到CPU的发展经历了从单核单线程到现在的多核多线程，但是内存的读写性能无法供给CPU的解决能力，所以增加了缓存。至于上一篇文章提到的三级缓存为什么是三个，不在本文讨论范围之内。我有兴趣亲自看看。 为什么会有能见度问题？单核时代，所有线程都交给一个CPU串行执行，所以无论多少个线程排队执行，都不会出现线程A和B同时竞争目标变量的情况，如图1所示。 image.png到了多核多线程时代，每个CPU都有自己的缓存。如果多个线程运行在不同的CPU上，并且需要同时操作相同的数据。 每个CPU在内存中求解数据时，会先将目标数据缓存到CPU缓存中。 这时候CPU做自己的事情，不管目标值有没有被其他CPU修改过，都不管3721，写回缓存。这一定不好，兄弟...而这就是我们在Java中常说的数据可见性的问题。追根溯源是:CPU级缓存一致性协议。 文章后面会详细解释(不要问具体时间，问的话就是明天) 能见度问题怎么处理？这很简单。如果它只处理可见性，那么就用Volatile关键字(这个关键字不是万能的，所以要慎重考虑)。它会把共享变量数据从线程工作内存刷新到主存，这个关键字的实现是基于Java规范的内存模型。注意要和JVM内存模型区分开来，两者是两码事。 那么Java内存模型是什么样的呢？为什么要设计这种内存模型？有什么好处？下一部分详细解释！先放一张本文简单的图片:图像罪2:原子性。大家都知道CPU的运行时间是分块的。可能CPU正在执行我这次写的if-else。下一刻，由于操作系统的调度，当前线程丢失了时间片，去执行其他线程任务了(呸！渣男) 打断了我当前线程的一个或多个操作进程，也就是原子性被破坏了，也就是多线程无锁情况下的ABA问题。 和我们预想的完全不一样。我们看图说话:image解释说:我想得到temp为2的结果，但只能得到1。原因是运行线程A的CPU在做别的事情。这时线程B所在的CPU做了A，先完成++运算，写回内存。但是A不知道，傻傻的以为是temp的初恋，然后就去写了，然后心态就崩溃了。偷袭~(错误)罪状三:有序如果原子问题是硬件工程师挖的坑(CPU不切换多好)，那么正确的顺序是软件工程师放下捕鼠器(夸张了，其实都是为了效率) 存在有序性问题的原因是伟大的编译器关心我们，知道我们普通的编码器对性能的要求是能够运行。 因此，Java代码在编译期间被操纵过，例如:锁消除、锁粗化(需要转义分析等技术手段)或者A、B两个操作按顺序互换。 但是，这一切都不能影响单线程执行情况下源代码的最终结果，也就是as-if-serial语义。 这是一个顶层协议，编译器、运行时状态和解析器必须遵守这个语义。 这是保证程序正确性的前提。 当然，编译器不仅要遵守as-if-serial的语义，还要遵守以下八条规则——发生之前的规则:什么是发生之前的规则？在程序中，前一个操作的结果对后面的操作是可见的。 就是无论怎么编译优化(优化的文章后面会写，关注我，都是免费的)，都不能违背这个指导思想。 忘不了原图注:文中所有类似“之前”、“早于”的词语都不严谨，不能等同于发生——之前，但这样认识比较好。更准确的含义是，操作结果对后者是可见的。 实际上，简单来说，就是JMM、编译器和程序员之间的关系。 JMM对程序员说:你按顺序写，执行结果按你写的顺序执行。任何BUG都是自己的问题。 程序员:好吧，随你怎么说！JMM对编译器说:你不能随意改变程序员的代码顺序。我答应他你想写什么就写什么。不要犯错误。 编译器:收到！(不过我还是想优化一下，只要不影响你就行。我来做这个优化，奥利。这里！)所以有这些规则，我们这些粗人是看不见的。理解他们就可以了！感谢各位看官！作者:罗拉跑跑跑跑参考链接:https://www.cnblogs.com/RollerRunning/p/14047049