过了这个村没这个老王的博客

乐观锁虽然去除了锁操作，但是一旦发生冲突，重试的成本非常高。这是两种最基本的处理方式，更高级别的锁都会选择其中一种来实现，比如读写锁就既可以基于互斥锁实现，也可以基于自旋锁实现。用队列把请求锁的线程排队，按照先来后到的顺序加锁即可，当然读线程仍然可以并发，只不过不能插队到写线程之前。读写锁是有倾向性的，读优先锁很高效，但容易让写线程饿死，而写优先锁会优先服务写线程，但对读。当你无法判断锁住的代码会执行多久时，应该首选互斥锁，互斥锁是一种独占锁。CAS相对用的较少，没啥特别高的并发量，锁还是方便的。

高并发下传输大文件，我们上文提到过，大文件难以命中 PageCache 缓存，又带来额外的内存拷贝，同时还挤占了小文件使用 PageCache 时需要的内存，因此，这时应该使用直接 IO。这两点可以看到 PageCache 的优点，它在 90% 以上场景下都会提升磁盘性能，但在某些情况下，PageCache 会不起作用，甚至由于多做了一次内存拷贝，造成性能的降低。你可以回忆下，没用零拷贝时，为了传输 320MB 的文件，在用户缓冲区分配了 32KB 的内存，把文件分成 1 万份传送，然而，

默认64位系统分配区数为：cpu核数*8，如当前环境16核系统分配区数为128个，每个64M上限的话最多可达8G，限制上限后，后续不够的申请会直接走mmap分配和munmap回收，不会进入ptmalloc2的buffer池。不过本质上，它是哈希表的变种，限制每个哈希桶只有 1 个比特位，所以，虽然它消耗的空间更少，但仅用于辅助数据的主索引，快速判断对象是否存在。（当然，JVM的内存逃逸分析会帮我们把一些分配在堆中的对象直接分配在找上，加速运行）（栈的容量有限，如 CentOS 7 中是 8MB 字节）

从 4 个方面来梳理，这其实就是我们在提升一个新系统的性能时，可以入手的 4 个层次。