jvm lock低性能分析

日志平台client面临着输出日志的问题。为了避免干扰业务系统，我们采用异步输出的方式。这实际上相当于一个多生产者-单消费者的多线程模型。传统的方式是使用同步加锁的方式，但是这种方式不够高效。之前 钟柱 分享过一个topic。当时没完全听懂。这次对这个问题再次研究了下。

传统lock低效的原因总结如下：

1 总的来说同步的目的有两个，保证写入的顺序；保证写入的东西被正确的读到；

2 lock的实现会导致虚拟机切换到系统内核状态，从系统内核挂起其他线程，直到lock被释放；切换很花时间；而且挂起其他线程也要花费时间；而且挂起后将会导致cache的失效；

3 如果不用lock，也可以使用CAS的方式实现对变量的独占访问。Cas是cpu提供的一种机器指令，不需要切换到内核状态。Java util下的哪些atomicXXX就是使用的这种方法。问题是使用这种方法难以实现复杂的同步机制。更重要的是，即使写成功了，还是要通知别的线程数据已经改变，以阻止他们读到错误的数据；

4 数据更改的通知是通过memory barrier来实现的。现代计算机的一个特点是，数据可能存在多个地方，register，processor的cache，内存里。各个processor的cache是独立。当一个变量发生修改时，需要通过一个消息协议，更新该变量的所有备份。在更新完成之前，所有的线程都必须等待；

5然后是处理器的缓存。大家知道cpu每次读内存都会将连续的若干字节读入到cache中。如果cpu顺序访问这些内存，那么cahce就会命中，就避免了读内存。但问题是如果读入cache的内存包含多个变量，并且分别被不同的线程修改，那么处理器必须多次进行memory读取的操作，从而降低了性能。由于同样的原因，使用array的性能高于使用linklist和tree的性能。

6 最后是队列的问题。队列的head，tail和size通常会读到cache中，然而，多个线程会同时修改它，导致竞争的发生。而且queue的底层使用linklist或者arraylist，会导致大量的gc的发生；

针对这些问题一帮人提出了Disruptor框架，可以极大的提高读写并发的性能。