浅谈关于Java中TimeZone锁竞争引发的问题解决
更新时间：2026年02月06日 09:04:42 作者：桦说编程
本文主要介绍了浅谈关于Java中TimeZone锁竞争引发的问题解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
背景
在高并发服务的性能排查中，我们通过线程 dump 发现了大量线程阻塞在同一把锁上。本文将详细分析问题根因，并介绍我的优化方案。
问题发现
在生产环境进行 thread dump 时，发现多个工作线程（20+）处于 BLOCKED 状态，等待同一个 Class 对象锁：
at java.util.TimeZone.getTimeZone(TimeZone.java:549)
- waiting on java.lang.Class@37b99a71
at org.joda.time.DateTimeZone.toTimeZone(DateTimeZone.java:1250)
at org.joda.time.base.AbstractDateTime.toGregorianCalendar(AbstractDateTime.java:296)
at xxx.common.DateTimeUtils.toCalendar(DateTimeUtils.java:469)
at xxx.business.RefundEndorseBusiness.doSetRefundEndorseFee(...)
...
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642)
关键信息：
- 阻塞位置:
java.util.TimeZone.getTimeZone - 等待对象:
java.lang.Class@37b99a71（类锁） - 调用来源: Joda-Time 的
DateTimeZone.toTimeZone()方法
问题分析
JDK TimeZone.getTimeZone 的锁机制
TimeZone.getTimeZone(String ID) 方法内部实现使用了 synchronized 关键字：
public static synchronized TimeZone getTimeZone(String ID) {
// 从缓存或文件加载时区信息
...
}
这意味着所有调用该方法的线程都需要竞争同一把类锁。
Joda-Time 的调用链
分析 Joda-Time 源码，DateTime.toGregorianCalendar() 的实现如下：
// org.joda.time.base.AbstractDateTime
public GregorianCalendar toGregorianCalendar() {
DateTimeZone zone = getZone();
GregorianCalendar cal = new GregorianCalendar(zone.toTimeZone());
cal.setTime(toDate());
return cal;
}
每次调用都会执行 zone.toTimeZone()，最终触发 TimeZone.getTimeZone()。
问题根因
┌─────────────────────────────────────────────────────────────────┐
│ 高并发请求 │
└─────────────────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ Thread-1 Thread-2 Thread-3 ... Thread-N │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ toCalendar() toCalendar() toCalendar() toCalendar() │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ toGregorianCalendar() ──────────────────────────────────── │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ toTimeZone() ───────────────────────────────────────────── │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌──────────────────────────────────────────────────────────┐ │
│ │ TimeZone.getTimeZone() - synchronized 类锁 │ │
│ │ │ │
│ │ Thread-1: 获取锁，执行中... │ │
│ │ Thread-2: BLOCKED (waiting on java.lang.Class) │ │
│ │ Thread-3: BLOCKED (waiting on java.lang.Class) │ │
│ │ ... │ │
│ │ Thread-N: BLOCKED (waiting on java.lang.Class) │ │
│ └──────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘
核心问题：
- 每次时间转换都触发
toTimeZone()调用 TimeZone.getTimeZone()是同步方法（JDK 8）- 高并发下大量线程竞争同一把类锁
- 实际业务中时区种类非常有限（如仅
Asia/Shanghai、UTC等）
原始实现
public static Calendar toCalendar(DateTime dateTime) {
Calendar result;
if (dateTime == null || DateTimeUtils.isLogicMin(dateTime)) {
result = new GregorianCalendar(1, 0, 1, 0, 0, 0);
result.setTimeZone(TimeZone.getTimeZone("UTC"));
return result;
}
if (DateTimeUtils.isLogicMax(dateTime)) {
result = new GregorianCalendar(9999, Calendar.DECEMBER, 31, 0, 0, 0);
result.setTimeZone(TimeZone.getTimeZone("UTC"));
return result;
}
// 问题所在：每次都调用 toGregorianCalendar()
result = dateTime.toGregorianCalendar();
return result;
}
优化方案
设计思路
由于底层API在项目中频繁使用，全部改动风险比较大，我也不想因为出错而背锅，所以考虑消除锁竞争的方案。
既然时区数量有限，我们可以缓存 DateTimeZone 到 TimeZone 的映射，避免重复调用 toTimeZone()。
技术选型：为什么选择 Caffeine
| 方案 | 优点 | 缺点 |
|---|---|---|
| HashMap + synchronized | 实现简单 | 锁粒度粗，与原问题类似 |
| ConcurrentHashMap.computeIfAbsent | JDK 原生，无依赖 | 首次加载时仍有锁竞争；长 key 可能 hash 冲突 |
| Caffeine | 高性能、自动驱逐、统计监控 | 引入额外依赖 |
| Guava Cache | 功能完善 | 性能略逊于 Caffeine |
选择 Caffeine 的原因：
- 高性能: 基于 W-TinyLFU 算法，近乎 O(1) 的读写性能
- 无锁读取: 读操作几乎无锁竞争
- 自动管理: 支持容量限制和自动驱逐
- 项目已有依赖: 无需引入新的 jar 包
优化后的实现
/**
* 缓存开关，驱逐时降级为直接调用
*/
static volatile boolean zoneCacheEnable = true;
/**
* DateTimeZone -> TimeZone 缓存
* 生产环境时区种类有限（通常 < 5 种），设置 maximumSize = 24 足够
*/
static LoadingCache<DateTimeZone, TimeZone> zoneCache = Caffeine.newBuilder()
.maximumSize(24)
.evictionListener((k, v, c) -> {
// 正常情况不应该触发驱逐，如果触发说明时区种类异常多
LOGGER.error("zone cache evicted k={}, v={}, cause={}", k, v, c);
zoneCacheEnable = false;
})
.build(DateTimeZone::toTimeZone);
/**
* 从缓存获取 TimeZone，带 fallback
*/
static TimeZone getTimeZoneFromCache(DateTimeZone zone) {
return zoneCacheEnable ? zoneCache.get(zone) : zone.toTimeZone();
}
/**
* 优化后的 toCalendar 方法
*/
public static Calendar toCalendar(DateTime dateTime) {
Calendar result;
if (dateTime == null || DateTimeUtils.isLogicMin(dateTime)) {
result = new GregorianCalendar(1, 0, 1, 0, 0, 0);
result.setTimeZone(TimeZone.getTimeZone("UTC"));
return result;
}
if (DateTimeUtils.isLogicMax(dateTime)) {
result = new GregorianCalendar(9999, Calendar.DECEMBER, 31, 0, 0, 0);
result.setTimeZone(TimeZone.getTimeZone("UTC"));
return result;
}
// 优化：从缓存获取 TimeZone，避免锁竞争
DateTimeZone zone = dateTime.getZone();
TimeZone timeZone = getTimeZoneFromCache(zone);
GregorianCalendar cal = new GregorianCalendar(timeZone);
cal.setTime(dateTime.toDate());
return cal;
}
优化前后对比
优化前： ┌─────────────────────────────────────────────────────────┐ │ N 个线程同时调用 toCalendar() │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ TimeZone.getTimeZone() - synchronized 类锁 │ │ │ │ 所有线程串行等待 │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘ 优化后： ┌─────────────────────────────────────────────────────────┐ │ N 个线程同时调用 toCalendar() │ │ │ │ │ ▼ │ │ ┌─────────────────────────────────────────────────┐ │ │ │ Caffeine Cache - 无锁读取 │ │ │ │ 所有线程并行获取缓存的 TimeZone │ │ │ └─────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────┘
关键设计决策
1. 为什么设置 maximumSize = 24
- 国内业务主要涉及
Asia/Shanghai、UTC、Asia/Hong_Kong等少数几个时区 - 如果超过 24 个不同时区，说明数据异常，触发告警
2. evictionListener 的作用
.evictionListener((k, v, c) -> {
LOGGER.error("zone cache evicted k={}, v={}, cause={}", k, v, c);
zoneCacheEnable = false;
})
- 正常情况下不应该触发驱逐（时区数量 < 8）
- 如果触发，说明：
- 存在异常数据导致时区种类过多
- 或者缓存配置需要调整
- 记录错误日志便于排查
- 禁用缓存作为 fallback，避免频繁驱逐带来的性能损耗
3. volatile 关键字的使用
static volatile boolean zoneCacheEnable = true;
- 保证多线程间的可见性
- 允许在发现异常时快速降级
总结
通过引入 Caffeine 缓存，我们成功消除了 TimeZone.getTimeZone() 的锁竞争问题。这个优化的核心思想是：对于数量有限、创建成本高的对象，使用缓存来换取并发性能。
不要使用过时的API。
到此这篇关于浅谈关于Java中TimeZone锁竞争引发的问题解决的文章就介绍到这了,更多相关Java TimeZone锁竞争内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
您可能感兴趣的文章:
相关文章
EasyExcel核心实战之Excel合并单元格,在线编辑与导出全攻略
在日常业务开发中,Excel 报表三个字往往意味着复杂、凌乱和无限的加班,本文提供了一套完整的 EasyExcel 解决方案,涵盖三大核心场景, 即合并单元格,在线编辑和数据导出,感兴趣的小伙伴可以了解下2026-05-05
JSP文件一般有两个存放位置,本文主要介绍了JavaWeb项目中JSP访问的问题解决,具有一定的参考价值,感兴趣的可以了解一下2024-01-01
这篇文章主要介绍了spring实现bean对象创建代码详解，具有一定借鉴价值,需要的朋友可以参考下2017-12-12
本文探讨了Java8中CompletableFuture的原理和应用,详解其异步编程能力、工作机制及实际使用方法,CompletableFuture通过链式调用和状态管理优化异步任务,提高Java应用的效率和性能2024-09-09
这篇文章主要介绍了解决idea每次新建项目都需要配置maven，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2020-09-09
Java利用Spire.PDF for Java实现添加、设置和删除PDF图层
PDF文档作为信息交换的通用格式,其内容的组织与管理至关重要,而PDF图层正是实现这一目标的神器,下面小编就为大家详细讲讲如何使用Java高效操作PDF图层吧2025-10-10
Mybatis逻辑分页与物理分页PageHelper使用解析
这篇文章主要为大家介绍了Mybatis逻辑分页与物理分页PageHelper使用解析,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪2023-12-12
这篇文章主要介绍了Java中super和this关键字详解，文章围绕主题展开详细的内容介绍，具有一定的参考价值，需要的小伙伴可以参考一下2022-06-06
本文提出通过自定义SpringCache的CacheResolver实现多租户数据隔离,动态添加租户标识至缓存键,解决缓存污染、数据泄露及失效范围控制问题,需要的朋友们下面随着小编来一起学习学习吧2025-09-09
今天在Idea中用Tomcat跑一个Web项目，启动后，Tomcat日志在控制台打印出来都是乱码，初次遇到这个问题真的很棘手，今天小编带领大家一起看看解决方法2018-07-07
最新评论