我要评论背景
在高并发服务的性能排查中，我们通过线程 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锁竞争内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网！
发表评论