面试官：你见过什么牛逼的代码？
The following article is from yes的练级攻略 Author 是yes呀
你好呀，我是why。
昨天我不是发了《这波优化，太炸裂了！》这篇文章嘛。
主要是分析了 HikariCP 连接池中四个角度的优化：
字节码级别的优化-尽量的利用 JIT 的内联手段 字节码级别的优化-利用更容易被 JVM 优化的指令 代码级别的优化-利用改造后的 FastList 代替 ArrayList 代码级别的优化-利用无锁的 ConcurrentBag
其实写文章之前，我每个点都想仔仔细细的写一下的。
后来字节码级别的优化写完之后，文章都已经近万字了。再把代码级别的优化写完的话，那怕读者看着累，再说了，我身体也扛不住啊。
而且我觉得字节码级别的优化才是最有意思的（虽然学会了对于日常开发也没啥卵用）。
所以，我把重心放到了字节码的部分。关于代码级别的 ConcurrentBag 部分，我就这样“巧妙”的写过去了：
巧了，今天看到有读者看了我的文章后，在群里发了一篇 yes 同学的文章。
写的就是 ConcurrentBag。
那我就不客气了，借花献佛，给大家分享一下。
以下是 yes 同学的正文。看完觉得不错，可以给 yes 老铁点点关注。
今天给大家剖析下一个叫 ConcurrentBag 的并发集合类，对 C# 熟悉的同学应该听过这个名字，不过我今天介绍的是 HikariCP 中的 ConcurrentBag。
我们知道 SpringBoot 默认连接池就是 HikariCP，而 HikariCP 就是以快著称的，而这个快离不开 ConcurrentBag。
如果你看过很多源码你就会发现好多框架都会自定义集合类，因为 JDK 通用的集合需要照顾到很多场景，而定制化肯定优于普适化。
像 HikariCP 就没有用 ArrayList 而是定义了一个 FastList，因为 ArrayList 每次 get 都会有范围检查，并且 remove 是从前往后遍历的。
而在 HikariCP 这个场景每次 get 范围检查没有必要，并且 remove 的时候从后往前遍历更好，所以就定制化了。
HikariCP 还有很多优化，这篇文章我们就谈谈其中之一，也就是今天的主角就是 ConcurrentBag 。
不过今天的目的不是为了分析 HikariCP ，而只是介绍这个集合类。
从它身上找点优化的思路，到时候像面试官问你：
如果让你优化一个连接池的性能，你会怎么做呀？
你就故作沉思的说：哎呀，我有个优化思路。
ConcurrentBag
一般而言我们设计一个连接池的初始想法是用锁来保证线程安全，或者用一些线程安全的并发容器来存储连接。
而 HikariCP 不满足于此，它专门设计了 ConcurrentBag 用来存数据库连接，当 HikariPool#getConnection 的时候就是去 ConcurrentBag 拿连接。
ConcurrentBag 整体就是无锁设计，有三个重要的成员变量：
ThreadLocal 缓存，加快本地连接获取速度 CopyOnWriteArrayList，写时拷贝List SynchronousQueue，无存储的等待队列
获取数据库连接基本流程如下。
第一步
当取连接的时候会先去 ThreadLocal 去找以前用过的连接，如果找到连接状态是可以使用的话，直接返回。
因为 ThreadLocal 是本地资源，每个线程都优先去自己本地去找，所以竞争也更少，需要遍历的连接也更少，所以速度就更快。
第二步
找不到再去 sharedList 这个共享的写时复制列表中查找可用连接。
第三步
如果再找不到，则通过 handoffQueue 等待可用的连接，如果超过一定时间则返回 null。
其实这种思想很简单。
每个线程一开始本地资源肯定是空的，然后每个线程把自己用过的连接存起来，之后优先用存着的链接。
久而久之每个线程都会有自己的本地存储的连接，这样大家都用自己的就少了竞争，那速度不就快了？
我们再来看下取连接的源码，里面还是有一些细节的。
其实应该叫借连接，因为要还的，而且也不是把连接从 ConcurrentBag 移除，只是返回一个引用罢了。
细节已经在代码上标注了，这里强调一下借连接不是移除连接，别的线程还是能通过 sharedList 找到这个连接的，无非这个连接如果被占用则状态是 STATE_IN_USE，这样别的线程就不会用这个连接了。
总体思路就是从本地找，没有的话再去每个线程都能访问的 sharedList 找，再没有就等着。
这里还有个窃取的概念，其实没什么花头，就是充分利用连接。
无非就是本来属于某个线程的本地连接，当它归还连接的时，恰巧有另一个线程从 sharedList 遍历找到这个连接，这时候连接的状态是 STATE_NOT_IN_USE，那么这个连接就会被另一个线程也保存到 ThreadLocal 中了。
这就是窃取。
我们再来看下归还连接的代码，连接就是在这里保存到 ThreadLocal 中的。
我在《HikariCP数据库连接池实战》这本书中看到，归还连接的代码在 HikariCP 2.6.0 是长下面这个样子的
当前归还连接的线程需要等这个连接被其他线程取走时或者没有等待线程时才能摆脱这个循环。
但是会出现一种情况：
在设置连接为可用时，这个连接已经被其他线程借走了，然后当前线程还傻傻的执行循环，而恰巧等待线程一直有，但是每次 handoffQueue.offer 就是没线程取，然后 yield ，如此往复。
这就造成明明连接已经归还了，而归还的线程还做无用功的自旋操作。
所以就做优化成上面的代码，如果 bagEntry.getState() != STATE_NOT_IN_USE 说明已经被别的线程借去用了，所以直接 return。
最后再提一提 CopyOnWriteArrayList 吧。
连接池是一个典型的读多写少的场景，所以写时复制用在此处再合适不过了。
简单的说：写操作的时候会复制当前的 list 来做修改，等修改完了再替换老的 list。
在替换之前读的线程读取的是老的 list 的数据，这样就能做到读的时候是无锁的。
写时复制的缺点就是内存的占用，因为需要拷贝一份数据，如果数据很大的话那就需要考虑内容的占用量了。
比如操作系统进程的 fork 操作也会用到写时复制，子进程和父进程一开始共享数据，当有修改的时候就会拷贝一份。
在 Redis 的 BGSAVE 命令或者 BGREWRITEAOF 命令的过程中就会 fork 子进程来进行后台操作，而此时 Redis 的哈希表扩容的负载因子就会变大，来避免 fork 期间不必要的内存写入操作 (扩容)。
总结
所以 ConcurrentBag 的优化思路就是本地缓存有的去本地缓存找连接，找不到就去公共的 sharedList 去找，还找不到就等着。
通过将连接本地存储化来减少竞争，又根据连接池读多写少的特性用 CopyOnWriteArrayList 来实现 sharedList 。
当然还有像上面 borrow 和 requite 的一些细节也值得品味，追求极致速度就需要扣细节。
不知道有多少同学是看到封面进来的。
这封面不是我搞的，是 yes 同学的原始封面，跟我可没关系啊。
想要找他去，文首可以直达他的公众号，他多的很。
就这样。
我是 why，一个主要写代码，经常写文章，偶尔拍视频的程序猿。
欢迎关注我呀。