引子

近期和客户(某国内互联网大厂)合作,优化他们的Hive on Cloud项目, 发现并修复了一些并发问题, 一个对技术感兴趣的实习生同事小T和我讨论了一些技术细节问题, 使我有个想法, 想把个人对并发(我这里说的并发是指Java/C++这种共享内存模式的并发,不是指Actor或协程那些)的一些理解, 系统的记录下来.
要深入理解并发, 涉及到少许硬件基本知识, 操作系统的线程进程以及进程间通信的知识(可以Linux内核为例). 在这些基础上, 才能更好的理解更高一级的抽象: 比如互斥锁,信号量等.

1. 概念太多,不同层次的抽象,各个分支, 如何有组织有条理的阐述?

CPU的内存模型, Java的内存模型, 高层抽象的mutex, semaphore, condition等, 重入锁, 读写锁. 还有什么自旋锁,偏向锁等等. 总之概念很多.

1. 深入程度怎么把握, 细节蔓延的太多, 会不会影响条理和简洁.

比如对互斥锁信号量等锁的理解: 就是一个状态变量(锁变量)/原子操作,另一个是线程阻塞/唤醒队列的管理,很简单. 但是如果打破砂锅问到底, 可以对细节很深入了解. 比如Java的ReentrantReadWriteLock, 实现里有个sync(用作同步), 需要了解AbstractQueuedSynchronizer类以及primitive LockSupport/UNSAFE的实现. 继续深入, 看去看JVM是如何用pthread_cond_t/pthread_mutex_t等pthread api实现的; 再深入, pthread(glibc的NPTL)又是怎么做的(glibc的代码非常非常的难读). 继续没完没了, 再深入就需要理解NPTL的基础即Linux系统调用futex, 再深入就看futex在内核是怎样实现的. 也许没有必要关注所有细节, 但了解各个层次实现的核心逻辑还是很有好处的.
还有, 比如用java的线程池ThreadPoolExecute, 如何处理InterruptedException, 以及为什么要这么处理, interupt到底怎么回事, 在JVM层怎么实现?操作系统里怎么回事?

要把这些知识整理得深入浅出是要水平的,很花精力和时间. 我非常认同左耳朵耗子说的, 技术文章要写得在马桶上拉屎时都能看懂才是好文章:-) 但这其实要求很高,要有深入理解和很好的有条理的表达. 而我水平和精力都有限, 先随便瞎写, 权作笔记了. 可读性和条理有空再整理.

开源社区报出来的两个高并发性能问题很有意思, 一个Spark的性能问题 和一个Cassandra的性能问题, 涉及到:

• Scala Scalability Issue
• instanceOf在HotSpot中的实现和优化
• CPU Cache thrashing / NUMA

从应用层(大数据)到JVM(HotSpot)instanceOf的实现, 再到CPU的硬件机制, 涉及到知识很有意思, 是一个很典型的问题, 对用Java/C++写多核心的高并发代码有启发, 把涉及到的知识拓展和小结一下.

调试HotSpot的环境配置的资料确实比较少. 想提交patch或者有时候好奇需要深入一下JVM看看具体的实现, 需要配置下开发环境. 这里记录整理一下.
有人写过Mac上配置, Windows的环境没查到,我也没弄过, 估计宇宙第一IDE的Visual Studio应该很好使:-)

WannaCry这阵子让很多人欲哭无泪， 感染蠕虫后， 网上各种分析和破解办法，然而没有能彻底解决问题的方法. 因为WannaCry的RSA+AES加密套餐，文件被AES算法加密, 而AES的key用RSA算法加密了. 理论上, 目前很难破解.
由此，扯扯密码学原语(cryptographic primitives). 简单评估下JDK里加密算法的性能，还有怎么选择合适的加密算法?
再探究一下AES算法的硬件加速和优化的工程实现。

看了篇微信后台异步化改造的文章, libco协程库加上epoll处理高并发. 企鹅厂是C++控, 后台用C++. 微信这种高并发, 见识了协程的用途. C/C++语言不提供协程的语义. 听过有人用setjmp/longjmp或ucontext实现协程, 一直对这种用户态切换没细看, 估计和操作系统切换进程类似, tss保存起来. 好奇心起, 趁机了解一下协程的实现, 同时整理一下进程/线程的原理.

转几个写得深入浅出的基础知识文章(有空再更新)：

几年前曾给同事做过一个java内存模型的knowledge sharing, 摘取部分内容放这, 简单的回顾下内存模型, 然后从JVM hotSpot实现的角度来仔细看看volatile的语义. 就此契机,整理出来.

在学习C++11多线程的时候，会碰到一大堆概念，mutex, lock, atomic, memory model, memory barrier， lock-free等。要更好的理解，可以：

1. 了解CPU的Memory Barriers机制(Paul McKenny的Memory Barriers: a Hardware View for Software Hackers)。了解CPU内部不同的核是怎么同步cache的，很有意思。这是理解memory order的基础。
2. 然后看Jeff Preshing的blog, 他的帖子深入浅出，写得非常好。
3. 《C++ Concurrency in action》, 作者是boost thread的作者。讲stl的thread的接口。
4. 再看看Herb Sutter,Hans Boehm等人的文章。 Bartosz Milewski的博客也值得看看.

double-checked locking是一个用来学习多线程的好例子。 Scott Meyers和Andrei Alexandrescu两位大牛写过一篇paper，讨论了double-checked实现的困难(Java的memeory model没有完善之前有同样的问题). Jeff Preshing写篇文章讨论这个问题.

看完大牛们的文章, 一步一步来动手实现一个Singleton，最后用template泛化.

最近在看C++ Memory Model, 顺便读了Hans-J. Boehm的10年前的paper Threads Cannot be Implemented as a Library。
C++多线程库有很多，但Boehm指出，C++的多线程库大多数情况是OK的，但在有些情况下是有问题的，并列举了三种情况。此外，因库隐藏了底层现实，在追求极致性能的地方使用库有限制。Boehm的结论是：C++必须在语言层面上支持多线性。正因Boehm和Herb Sutter的努力，C++11支持了多线程。

Boehm大叔以POSIX的规范pthread为例，进行详细的论述，简单总结如下：

C++11加入了rvalue reference的概念后，类型推导规则更加复杂了。微软的Stephan Lavavej在Channel9的Core C++系列中对deduction简单地做了些介绍 ，但并没有深入地讲。我拿C++标准研究了一把，发现deduction的规则细节还是比较繁琐的。标准文档的可读性不太好，颇费脑细胞. 相对而言cppreference可读性要好一些。这篇主要总结函数调用时的类型推导(Deduction from a function call)和不进行类型推导的几种情况(Non-deduced contexts)