news 2026/6/22 16:27:42

读懂HikariCP一百行代码,多线程就是个孙子

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
读懂HikariCP一百行代码,多线程就是个孙子

总结:Java届很难得有读百十行代码就能增加修炼的机会,这里有一个。

通常,我在看书的时候一般不写代码,因为我的脑袋被设定成单线程的,一旦同时喂给它不同的信息,它就无法处理。

但多线程对电脑来说就是小菜一碟,它可以同时做很多事,看起来匪夷所思。好希望把自己的大脑皮层移植到这些牛x的设备上。

用人脑思考电脑正在思考的问题,这本身就是一种折磨。但平常的工作和面试中,又不得不面对这样的场景,所以多线程就成了编程路上一块难啃的骨头。

HikariCP是SpringBoot默认的数据库连接池,它毫不谦虚的的起了一个叫做的名字,这让国产Druid很没面子。

还是言归正传,看一下Hikari中的ConcurrentBag吧。

核心数据结构

多线程代码一个让人比较头疼的问题,就是每个API我都懂,但就是不会用。很多对concurrent包倒背如流的同学,在面对现实的问题时,到最后依然不得不被迫加上Lock或者synchronized。

ConcurrentBag是一个Lock free的数据结构,主要用作数据库连接的存储,可以说整个HikariCP的核心就是它。删掉乱七八糟的注释和异常处理,可以说关键的代码也就百十来行,但里面的道道却非常的多。

ConcurrentBag速度很快,要达到这个目标,就需要一定的核心数据结构支持。

private final CopyOnWriteArrayList<T> sharedList; private final ThreadLocal<List<Object>> threadList; private final AtomicInteger waiters; private final SynchronousQueue<T> handoffQueue;
  • sharedList用来缓存所有的连接,是一个CopyOnWriteArrayList结构。

  • threadList用来缓存某个线程所使用的所有连接,相当于快速引用,是一个ThreadLocal类型的ArrayList。

  • waiters当前正在获取连接的等待者数量。AtomicInteger,就是一个自增对象。当waiters的数量大于0时候,意味着有线程正在获取资源。

  • handoffQueue0容量的快速传递队列,SynchronousQueue类型的队列,非常有用。

ConcurrentBag里面的元素,为了能够无锁化操作,需要使用一些变量来标识现在处于的状态。抽象的接口如下:

public interface IConcurrentBagEntry{ int STATE_NOT_IN_USE = 0; int STATE_IN_USE = 1; int STATE_REMOVED = -1; int STATE_RESERVED = -2; boolean compareAndSet(int expectState, int newState); void setState(int newState); int getState(); }

有了这些数据结构的支持,我们的ConcurrentBag就可以实现它光的宣称了。

获取连接

连接的获取是borrow方法,还可以传入一个timeout作为超时控制。

public T borrow(long timeout, final TimeUnit timeUnit) throws InterruptedException

首先,如果某个线程执行非常快,使用了比较多的连接,就可以使用ThreadLocal的方式快速获取连接对象,而不用跑到大池子里面去获取。代码如下。

// Try the thread-local list first final var list = threadList.get(); for (int i = list.size() - 1; i >= 0; i--) { final var entry = list.remove(i); final T bagEntry = weakThreadLocals ? ((WeakReference<T>) entry).get() : (T) entry; if (bagEntry != null && bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) { return bagEntry; } }

我们都知道,包括ArrayList和HashMap一些基础的结构,都是Fail Fast的,如果你在遍历的时候,删掉一些数据,有可能会引起问题。幸运的是,由于我们的List是从ThreadLocal获取的,它首先就避免了线程安全的问题。

接下来就是遍历。这段代码采用的是尾遍历(头遍历会出现错误),用于快速的从列表中找到一个可以复用的对象,然后使用CAS来把状态置为使用中。但如果对象正在被使用,则直接删除它。

在ConcurrentBag里,每个ThreadLocal最多缓存50个连接对象引用。

当ThreadLocal里找不到可复用的对象,它就会到大池子里去拿。也就是下面这段代码。

// Otherwise, scan the shared list ... then poll the handoff queue final int waiting = waiters.incrementAndGet(); try { for (T bagEntry : sharedList) { if (bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) { // If we may have stolen another waiter's connection, request another bag add. if (waiting > 1) { listener.addBagItem(waiting - 1); } return bagEntry; } } listener.addBagItem(waiting); // 还拿不到,就需要等待别人释放了 timeout = timeUnit.toNanos(timeout); do { final var start = currentTime(); final T bagEntry = handoffQueue.poll(timeout, NANOSECONDS); if (bagEntry == null || bagEntry.compareAndSet(STATE_NOT_IN_USE, STATE_IN_USE)) { return bagEntry; } timeout -= elapsedNanos(start); } while (timeout > 10_000); return null; } finally { waiters.decrementAndGet(); }

首先要注意,这段代码可能是由不同的线程执行的,所以必须要考虑线程安全问题。由于shardList是线程安全的CopyOnWriteArrayList,适合读多写少的场景,我们可以直接进行遍历。

这段代码的目的是一样的,需要从sharedList找到一个空闲的连接对象。这里把自增的waiting变量传递到外面的代码进行处理,主要是由于想要根据waiting的大小来确定是否创建新的对象。

如果无法从池子里获取连接,则需要等待别的线程释放一些资源。

创建对象的过程是异步的,要想获取它,还需要依赖一段循环代码。while循环代码是纳秒精度,会尝试从handoffQueue里获取。最终会调用SynchronousQueue的transfer方法。

归还连接

有借就有还,当某个连接使用完毕,它将被归还到池子中。

public void requite(final T bagEntry) { bagEntry.setState(STATE_NOT_IN_USE); for (var i = 0; waiters.get() > 0; i++) { if (bagEntry.getState() != STATE_NOT_IN_USE || handoffQueue.offer(bagEntry)) { return; } else if ((i & 0xff) == 0xff) { parkNanos(MICROSECONDS.toNanos(10)); } else { Thread.yield(); } } final var threadLocalList = threadList.get(); if (threadLocalList.size() < 50) { threadLocalList.add(weakThreadLocals ? new WeakReference<>(bagEntry) : bagEntry); } }

首先,把这个对象置为可用状态。然后,代码会进入一个循环,等待使用方把这个连接接手过去。当连接处于STATE_NOT_IN_USE状态,或者队列中的数据被取走了,那么就可以直接返回了。

由于waiters.get()是实时获取的,有可能长时间一直大于0,这样代码就会变成死循环,浪费CPU。代码会尝试不同层次的睡眠,一个是每隔255个waiter睡10ns,一个是使用yield让出cpu时间片。

如果归还连接的时候并没有被其他线程获取到,那么最后我们会把归还的连接放入到相对应的ThreadLocal里,因为对一个连接来说,借和还,通常是一个线程。

知识点

看起来平平无奇的几行代码,为什么搞懂了就能Hold住大部分的并发编程场景呢?主要还是这里面的知识点太多。下面我简单罗列一下,你可以逐个攻破。

  1. 使用ThreadLocal来缓存本地资源引用,使用线程封闭的资源来减少锁的冲突

  2. 采用读多写少的线程安全的CopyOnWriteArrayList来缓存所有对象,几乎不影响读取效率

  3. 使用基于CAS的AtomicInteger来计算等待者的数量,无锁操作使得计算更加快速

  4. 0容量的交换队列SynchronousQueue,使得对象传递更加迅速

  5. 采用compareAndSet的CAS原语来控制状态的变更,安全且效率高。很多核心代码都是这么设计的

  6. 在循环中使用park、yield等方法,避免死循环占用大量CPU

  7. 需要了解并发数据结构中的offer、poll、peek、put、take、add、remove方法的区别,并灵活应用

  8. CAS在设置状态时,采用了volatile关键字修饰,对于volatile的使用也是一个常见的优化点

  9. 需要了解WeakReference弱引用在垃圾回收时候的表现

麻雀虽小,五脏俱全。如果你想要你的多线程编程能力更上一层楼,读一读这个短小精悍的ConcurrentBag吧。当你掌握了它,多线程的那些东西,不过是小菜一碟。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/6/17 20:22:39

为什么头部保险公司都在用Open-AutoGLM做到期提醒?真相令人震惊,

第一章&#xff1a;为什么头部保险公司都在用Open-AutoGLM做到期提醒&#xff1f;真相令人震惊在保险行业数字化转型的浪潮中&#xff0c;客户保单到期提醒的自动化与精准化已成为提升续保率的关键环节。越来越多头部保险公司悄然采用名为 Open-AutoGLM 的开源智能提醒系统&…

作者头像 李华
网站建设 2026/6/20 13:42:37

C++类的构造顺序

1. C 类成员与自身的构造和析构顺序 默认先构造类成员&#xff08;类成员的构造顺序就是类成员在类中被书写的顺序&#xff09;&#xff0c;然后再构造类本身。参看 “测试代码 1”。默认先析构类本身&#xff0c;然后再析构类成员&#xff08;类成员的析构顺序就是类成员在类中…

作者头像 李华
网站建设 2026/6/17 1:51:41

YOLOv11 改进 - C2PSA | C2PSA融合DiffAttention差分注意力:轻量级差分计算实现高效特征降噪,提升模型抗干扰能力

前言 本文介绍了 DiffCLIP,一种将差分注意力机制集成到 CLIP 架构的视觉 - 语言模型,并将其应用于 YOLOv11。差分注意力机制通过计算两个互补注意力分布的差值,抵消无关信息干扰。单头差分注意力将 Q 和 K 拆分,分别计算注意力分布后做差值融合;多头差分注意力则每个头独…

作者头像 李华
网站建设 2026/6/22 3:50:12

体检报告查询进入AI时代:Open-AutoGLM究竟带来了哪些颠覆性变革?

第一章&#xff1a;体检报告查询进入AI时代&#xff1a;Open-AutoGLM的崛起随着人工智能技术在医疗健康领域的深度渗透&#xff0c;体检报告的智能解析正迎来革命性变革。传统依赖人工解读的模式逐渐被高效、精准的AI系统取代&#xff0c;而Open-AutoGLM作为新一代通用语言模型…

作者头像 李华
网站建设 2026/6/15 11:03:13

揭秘Open-AutoGLM智能纪要生成:如何5分钟自动生成高质量会议记录

第一章&#xff1a;揭秘Open-AutoGLM智能纪要生成&#xff1a;5分钟打造高质量会议记录在快节奏的现代办公环境中&#xff0c;高效、准确地生成会议纪要是提升团队协作效率的关键。Open-AutoGLM 作为一款基于大语言模型的开源工具&#xff0c;专为自动化会议纪要生成而设计&…

作者头像 李华
网站建设 2026/6/17 20:05:13

揭秘Open-AutoGLM待办同步黑科技:如何实现跨平台零延迟数据同步

第一章&#xff1a;揭秘Open-AutoGLM待办同步黑科技&#xff1a;跨平台零延迟的奥秘 在分布式任务管理场景中&#xff0c;Open-AutoGLM 凭借其创新的同步机制实现了跨平台待办事项的“零延迟”更新。这一能力背后融合了事件驱动架构、增量数据同步与智能冲突解决策略&#xff0…

作者头像 李华