java中时钟回拨,【追光者系列】HikariCP源码分析之evict、时钟回拨、连接创建生命周期...

最新推荐文章于 2025-06-15 23:09:07 发布
最新推荐文章于 2025-06-15 23:09:07 发布
阅读量519 收藏
点赞数
文章标签： java中时钟回拨
本文详细分析了HikariCP连接池中关于时钟回拨的处理，以及连接的创建、生命周期管理和驱逐策略。通过源码解读，阐述了`evict`如何标记和处理不可用连接，以及`getConnection`时的检查机制。同时，文章还探讨了`connectionTimeout`、`maxLifetime`参数的作用，并介绍了`softEvictConnection`的软驱逐机制。此外，还提及了HikariCP在时钟回拨情况下的应对策略。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

摘自【工匠小猪猪的技术世界】 1.这是一个系列，有兴趣的朋友可以持续关注 2.如果你有HikariCP使用上的问题，可以给我留言，我们一起沟通讨论 3.希望大家可以提供我一些案例，我也希望可以支持你们做一些调优

概念

evict定义在com.zaxxer.hikari.pool.PoolEntry中，evict的汉语意思是驱逐、逐出，用来标记连接池中的连接不可用。

getConnection

在每次getConnection的时候，borrow连接(PoolEntry)的时候，如果是标记evict的，则会关闭连接，更新timeout的值，重新循环继续获取连接

如下我们聚焦一下源码，hardTimeout默认值是30000，这个值实际上就是connectionTimeout，构造器默认值是SECONDS.toMillis(30) = 30000，默认配置validate之后的值是30000，validate重置以后是如果小于250毫秒，则被重置回30秒。

connectionTimeout  This property controls the maximum number of milliseconds that a client (that's you) will wait for a connection from the pool. If this time is exceeded without a connection becoming available, a SQLException will be thrown. Lowest acceptable connection timeout is 250 ms. Default: 30000 (30 seconds)

关闭连接这块的源码如下，从注释可以看到(阅读hikari源码强烈建议看注释)，这是永久关闭真实(底层)连接(吃掉任何异常)：

吃掉体现在quietlyCloseConnection,这是吃掉Throwable的

最低0.47元/天 解锁文章

200万优质内容无限畅学
时钟回拨问题是什么
u012534547的博客
09-18 1450
UUID：简单易用，适合不需要顺序性的分布式场景。Snowflake（雪花算法）：适合高并发、有顺序性需求的分布式系统，如数据库主键生成。数据库自增ID：适合对一致性要求较高、并发要求较小的场景。Redis INCR：适合高并发的分布式系统，需要依赖Redis的高可用性。Zookeeper 顺序节点：适合需要严格顺序性的场景。：Snowflake 的优化版本，适合多数据中心的分布式系统。每种方案都有各自的优缺点和应用场景，选择时需要根据系统的具体需求（如性能、并发量、顺序性、可用性等）进行权衡。
TEE-Watchdog: Mitigating Unauthorized Activities within Trusted Execution Environments in ARM-Based
baron-周贺贺-代码改变世界ctw
08-01 161
Anum Khurshid, Sileshi Demesie Yalew, Mudassar Aslam, and Shahid Raza 1. 引言 可信执行环境（TEEs）在我们周围的设备中迅速崛起，从大规模基于云的解决方案到资源受限的嵌入式设备。随着ARM TrustZone-M的引入，硬件辅助的可信执行现在也支持物联网节点。TrustZone-M提供了安全关键操作和敏感数据生成外围设备的隔离执行。然而，TrustZone-M与所有其他TEEs一样，不提供监控设备可信区域操作的机制，并且物联网设备安全
雪花算法-Java实现-解决时钟回拨的一种方法
tt5753的专栏
08-13 6559
一种可能是解决时钟回拨的方法, 仅改动代码, 不需要其他辅助.
Java面试题：分布式ID时钟回拨怎么处理？序列号耗尽了怎么办？
最新发布
啾啾头号大粉丝打工买粮博客
06-15 649
《分布式ID生成：时钟回拨与序列号耗尽问题解决方案》探讨了分布式ID系统的常见问题及应对策略。文章分析了典型分布式ID结构（如UUIDv7）的特点，针对时钟回拨问题提出四种方案：毫秒级等待、时钟回拨位机制、外部时钟依赖（如Redis）和混合时间戳方法。对于序列号耗尽问题，则给出等待下一时间戳、增加序列号位数、多ID生成器分片三种解决方案，并附上具体代码实现示例。本文系统性梳理了分布式ID生成的核心技术挑战，为开发者提供了实用的工程实践参考。
java timer时间回拨_追踪解析 Netty 的 HashedWheelTimer 源码
weixin_42131367的博客
02-26 395
零 前期准备0 FBI WARNING文章异常啰嗦且绕弯。1 版本JDK 版本 : Adoptopenjdk 14.0.1IDE : idea 2020.1Netty 版本 : netty-all 4.1.46.Final2 HashedWheelTimer 简介HashedWheelTimer 是 Netty 中实现延迟任务的工具类。3 Demoimport io.netty.util.Hash...
java 实现的数据查询缓存通用模型——缓存清除cacheEvict（2）
衡与墨的博客
06-11 1201
收录于墨的2020~2021开发经验总结 接续上文（Redis 实现的数据查询缓存通用模型（1）） 3、缓存清除cacheEvict 3.1 基本原理 在实际应用中，缓存并非是一成不变的，我们写入缓存之后还需要更新缓存。这常常存在于一些更新操作和删除操作中。 例如我们查询了一个产品列表的第一页，之后缓存写入了这一页，在缓存中我们有这样一个映射： key : DAWN-CACHE.cn.hengyumo.dawn.example.service.ProductService.searchProduct.siz
雪花算法中的时间回拨问题解决方案
热门推荐
或左的博客
04-20 1万+
什么是时间回拨问题 雪花算法通过时间来即将作为id的区分标准之一,对于同一台id生成机器,它通过时间和序号保证id不重复 当机器出现问题,时间可能回到之前,此时,时间就不能区分 又或者因为闰秒的出现,导致时间回拨 如何解决 方法1 直接抛出异常 不管3X7==21,直接抛出异常 将问题交给人工解决 这种方法也是原始的雪花算法,百度的uid-generator采用的 太过简单,显然不好 方法2 延迟等待 这种时间回拨(回跳)或许只出现一次,也许只是机器出现了小问题,所以产生 对于这种场景,没有必要抛
从源码角度带你分析 Spring Boot为什么如此受青睐 HikariCP了，这图太透彻，看完总算理解了
duan18888的博客
04-28 356
前言 现在已经有很多公司在使用HikariCP了，HikariCP还成为了SpringBoot默认的连接池，伴随着SpringBoot和微服务，HikariCP 必将迎来广泛的普及。 下面陈某带大家从源码角度分析一下HikariCP为什么能够被Spring Boot 请来，文章目录如下： 目录 零、类图和流程图 开始前先来了解下HikariCP获取一个连接时类间的交互流程，方便下面详细流程的阅读。 获取连接时的类间交互： 图1 一、主流程1：获取连接流程 HikariCP获
终于理解Spring Boot 为什么青睐HikariCP了，图解的太透彻了！
weixin_57907028的博客
07-30 358
前言 现在已经有很多公司在使用HikariCP了，HikariCP还成为了SpringBoot默认的连接池，伴随着SpringBoot和微服务，HikariCP 必将迎来广泛的普及。 下面陈某带大家从源码角度分析一下HikariCP为什么能够被Spring Boot 青睐，文章目录如下： 零、类图和流程图 开始前先来了解下HikariCP获取一个连接时类间的交互流程，方便下面详细流程的阅读。 获取连接时的类间交互： 一、主流程1：获取连接流程 HikariCP获取连接时的入口是Hika
Springcloud-注册中心-Eureka源码分析
F_Hello_World的博客
07-07 543
springCloud对于注册中心提供了很多的选择，例如实现CAP中AP的Eureka，实现了CP的zookeeper等，这里主要介绍使用的是给予Netflix的Eureka。 首先我们基于的springcloud的最新版本-Hoxton来介绍，这里使用的是springboot2.2.5，关于springboot与springCloud的版本对应关系可以参考下表： SpirngCloud Ve...
【线上处理经验】中间件问题：时钟回拨
我是Java程序员廖志伟，感谢朋友们的支持！
07-02 1768
时钟回拨发生在时钟向后移动的情况下，这通常是由于某些系统事件（例如操作系统重启）引起的。时钟回拨不仅会对系统本身造成影响，也会对系统外部调用（例如中间件）造成混乱。在分布式系统中，时钟回拨会导致消息的时间戳顺序错误，进而影响消息的正确性和完整性。因此，时钟回拨常常被认为是中间件处理的一个重要问题。时钟同步在分布式系统中是一个重要的问题。时钟回拨会影响消息的正确性和完整性，因此中间件需要采取相应的措施。
Hikaricp源码解读
10-24
深入开源连接池HikariCP，从源码解读HikariCP的速度优势来源！ ps：整理源码版本位v2.7.2
session.clear/evict
qq_44427169的博客
04-02 328
今天学到了session 的一些操作，对于clear, evict , flush方法的用途区别并没有很清楚，看到了一篇总结解释的很好，记录在自己的笔记中，方便以后回顾。 转载自https://blog.csdn.net/luxiangxing/article/details/83735405?utm_source=app ...
浅谈解决雪花算法的时钟回拨问题
qq_43513370的博客
03-24 1777
每个一段时间内保存过去一段时内 机器当前这一毫秒产生的 ID 的最大值，例如使用Map形式，就是<机器的id,最大值>,如果发生了时钟回拨，直接在这台机器对应的最大值继续自增生成 ID 即可。由于生成随机数时依赖于服务器的时间，加入机器发生了故障或者别的情况，对于服务器的时间进行了回拨，那么会导致生成的 ID 可能发生重复。第53-64的bit位：这12位表示序列号，也就是1毫秒内可以生成2的12方个不同的 ID。不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
聊聊hikari连接池的maxLifetime属性及evict操作
weixin_34206899的博客
02-03 5588
序 本文主要研究一下hikari连接池的maxLifetime属性及evict操作 maxLifetime属性及evict操作 maxLifetime 用来设置一个connection在连接池中的存活时间，默认是1800000，即30分钟。如果设置为0，表示存活时间无限大。如果不等于0且小于30秒则会被重置回30分钟。 evict 用来标...
Snowflake 时钟回拨问题 解决方案
大道至简
03-28 882
时钟回拨问题是指，在使用Snowflake算法的系统中，如果系统时钟回拨，可能会生成重复的ID。这是因为算法依赖于系统时钟来保证ID的唯一性，如果时钟回拨到了之前的某个时间点，系统可能会生成与之前相同的时间戳，从而导致ID冲突。在实际部署中，时钟回拨是非常罕见的，但是对于需要高可靠性的系统，这样的情况必须被考虑进去。：在某些实现中，如果检测到时钟回拨，系统可能会选择抛出错误或者进行降级处理，比如使用一个备用的ID生成策略。：如果检测到时钟回拨，系统将停止生成ID，直到系统时钟追上最后一次记录的时间戳。
Hibernate中clear()、evict（）、flush()的方法使用说明
lsnaruto的博客
12-18 8122
clear() 方法，把缓冲区的全部对象强制清除Session缓存。 evict()方法：会把指定的缓冲对象进行清除。 flush()方法：强制进行从内存到数据库的同步。 在介绍方法使用之前，先介绍几个关键字段： insertions:session在要保存数据时，要在insertions中登记应用的插入行为（包括：引用对象、对象id、session、持久化处理类）； entityE...
HikariCP--基础--04--原理
zhou920786312的博客
07-28 1217
到这里基本上一个连接的生产到获取到回收到废弃一整个生命周期在HikariCP内是如何管理的就说完了，相比之前的Druid的实现，有很大的不同，主要是HikariCP的无锁获取连接，本篇没有涉及FastList的说明，因为从连接管理这个角度确实很少用到该结构，用到FastList的地方主要在存储连接对象生成的statement对象以及用于存储线程内缓存起来的连接对象；
不定时过期的 LRU 算法
03-19
<think>嗯，用户问的是“不定时过期的LRU算法”，这我得先理清楚LRU本身的基础，再考虑不定时过期的部分。LRU是Least Recently Used的缩写，也就是最近最少使用算法，常用于缓存淘汰策略。它的核心思想是，当缓存空间不足时，优先淘汰最久未被访问的数据。 那不定时过期是什么意思呢？可能是指缓存中的每个数据项都有一个独立的过期时间，而这个时间可能不是固定的，或者每个项的过期时间可以不同。这时候，传统的LRU需要结合这样的过期机制，可能就形成了某种变种算法，比如结合了TTL（Time To Live）的LRU。 我需要先回顾一下标准LRU的实现方式。通常有两种方法：一种是使用链表和哈希表结合的方式，当访问某个数据时，将其移到链表头部，这样链表尾部就是最近最少使用的元素；另一种是记录每个元素的最后访问时间戳，淘汰时选择时间戳最早的那个。 当引入不定时过期后，每个缓存项可能有一个不同的过期时间。这时候，除了考虑访问时间，还要检查是否过期。比如，一个即使最近被访问过，但如果已经过期的项，也应该被淘汰。这时候，可能需要将LRU的淘汰策略和过期时间结合起来处理。 接下来需要考虑的是，如何在这种混合策略下高效管理缓存。可能的实现方式包括： 1. 每个节点除了记录访问时间，还要记录过期时间。当需要淘汰时，先检查哪些项已经过期，优先淘汰过期的项；如果没有过期项，再按LRU策略淘汰最久未使用的项。 2. 或者在每次访问缓存项时，不仅更新访问时间，还要检查是否过期，如果过期则直接移除，不再提供服务，并触发加载新数据。 但这样可能会增加每次访问的开销，因为需要检查过期时间。这时候需要平衡效率和准确性。例如，是否需要在每次访问时都严格检查过期时间，还是可以定期批量清理过期项。 另外，不定时过期的LRU可能在实际应用中需要考虑的问题包括： - 如何高效地管理具有不同过期时间的项。例如，使用优先队列（比如最小堆）来跟踪最近的过期时间，这样可以快速找到即将过期的项，但这可能与LRU的链表结构结合使用，增加复杂度。 - 当系统时间发生变化时（比如服务器时间被调整），如何处理过期时间的计算，这可能带来一些问题，需要确保时间计算的正确性。 举个例子，假设有一个缓存项A在10:00被访问，过期时间是30分钟后，即10:30。而另一个缓存项B在10:15被访问，过期时间是20分钟后，即10:35。此时如果缓存满了，当需要淘汰时，如果当前时间是10:25，那么A已经接近过期，而B还有10分钟。这时候应该优先淘汰A还是按照LRU的策略？ 可能需要根据具体的业务需求来决定。比如，如果过期时间更重要，那么即使A是更久未被访问，但因为它即将过期，可以先淘汰它。而如果访问频率更重要，可能还是按LRU处理。 不过，用户的问题中的“不定时过期”可能指的是每个项的过期时间可能不同，而不仅仅是固定时间间隔。这时候，可能需要将过期时间和LRU结合起来，设计一种混合的淘汰策略。 可能的实现步骤： 1. 每个缓存项保存最后访问时间和过期时间（可以是绝对时间或相对时间）。 2. 当访问一个项时，更新其最后访问时间，并可能重置过期时间（根据业务需求，比如每次访问后延长过期时间）。 3. 淘汰策略分为两步： a. 首先扫描所有项，移除所有已过期的项。 b. 如果仍有空间不足，再按照LRU策略淘汰最久未使用的项。 这样的方式结合了过期淘汰和LRU，但可能需要较高的维护成本，尤其是在频繁扫描过期项时，或者需要高效的数据结构来管理。 另一种方法是，将过期时间和LRU的顺序结合起来，比如维护两个优先级队列：一个按过期时间排序，另一个按最后访问时间排序。当需要淘汰时，先看是否有过期的项，如果有则淘汰；否则淘汰最久未使用的。 此外，可能还需要处理并发访问的问题，比如多线程环境下的锁机制，确保数据一致性。 可能的应用场景包括网页缓存，其中不同页面的缓存时间由服务器动态指定；或者API响应缓存，根据接口的不同设置不同的缓存过期时间。 总结来说，不定时过期的LRU算法是在标准LRU的基础上，为每个缓存项引入独立的过期时间，使得淘汰策略同时考虑访问时间和过期状态，从而更灵活地管理缓存。实现时需要结合两种机制，可能采用分阶段淘汰（先过期后LRU）或混合排序的方式，并选择合适的数据结构来优化性能。</think>### 不定时过期的 LRU 算法介绍 #### 1. **基础概念回顾** - **LRU（Least Recently Used）**：核心思想是淘汰**最久未被使用**的数据。例如，缓存满时，优先移除长时间未被访问的项。 - **不定时过期**：每个缓存项有**独立的过期时间**（例如：项 A 在 5 分钟后过期，项 B 在 10 分钟后过期）。 #### 2. **算法核心思想** 不定时过期的 LRU 是 **LRU + TTL（Time To Live）** 的结合体，淘汰策略需同时满足： 1. **过期优先**：已过期的项无论访问时间如何，必须淘汰。 2. **LRU 兜底**：若缓存未满且无过期项，则按 LRU 规则淘汰最久未使用的项。 --- #### 3. **实现步骤** **步骤 1：数据结构设计** - 每个缓存项需记录： - **最后访问时间**（用于 LRU 排序）。 - **过期时间**（绝对时间戳或相对时长）。 - 使用**双向链表 + 哈希表**管理 LRU 顺序，同时维护**过期时间的最小堆**（快速找到最早过期的项）。 **步骤 2：访问缓存项** - 若命中缓存： 1. 检查是否已过期： - **是**：直接移除，重新加载。 - **否**：更新最后访问时间，移动至链表头部。 - 若未命中：加载新数据并插入链表头部，记录过期时间，更新最小堆。 **步骤 3：淘汰策略** 1. **主动清理**：定期扫描最小堆，移除所有过期项。 2. **被动触发**： - 当缓存满且需要插入新数据时： - 先清理所有过期项。 - 若空间仍不足，按 LRU 规则淘汰链表尾部的项。 --- #### 4. **关键问题与优化** - **问题 1：如何高效管理过期时间？** - **优化方案**：使用**最小堆**按过期时间排序，每次淘汰时弹出堆顶元素（最早过期的项）。 - **代价**：插入/删除堆的时间复杂度为 $O(\log n)$。 - **问题 2：如何平衡过期淘汰与 LRU 顺序？** - **混合策略**：优先清理过期项，再使用 LRU 兜底。例如： ```python def evict(): while not cache.is_full(): expired_item = heap.pop() if expired_item is None: break cache.remove(expired_item) if cache.is_full(): lru_item = linked_list.tail cache.remove(lru_item) ``` - **问题 3：时间同步与精度** - 若系统时间被修改（例如服务器时钟回拨），需使用**相对时间**计算过期时间（例如：记录“存活时长”而非绝对时间戳）。 --- #### 5. **应用场景** - **动态缓存策略**：例如 CDN 中不同资源的缓存时间由业务动态指定。 - **会话管理**：用户会话的过期时间各异，需结合活跃度和过期时间淘汰。 - **数据库查询缓存**：不同查询结果的缓存有效期根据数据更新频率设置。 --- #### 6. **示例说明** 假设缓存容量为 3，按以下操作序列演示： 1. 插入项 A（过期时间：10:30），最后访问时间 10:00。 2. 插入项 B（过期时间：10:35），最后访问时间 10:05。 3. 插入项 C（过期时间：10:25），最后访问时间 10:10。 4. 在 10:20 访问项 B，更新其最后访问时间为 10:20。 5. 插入项 D（需触发淘汰）： - **步骤 1**：清理过期项（C 已过期）。 - **步骤 2**：剩余空间仍不足，按 LRU 淘汰最久未使用的项 A。 --- #### 7. **总结** 不定时过期的 LRU 算法通过**混合淘汰策略**（过期优先 + LRU 兜底），在传统 LRU 基础上增加了时间维度，适用于需要动态调整缓存生命周期的场景。其实现需权衡数据结构复杂度与性能，通常结合最小堆和双向链表来优化操作效率。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值