写了这么多年DateUtils,殊不知你还有这么多弯弯绕!
目录
大家好,我是哪吒。
在日常开发中,Date工具类使用频率相对较高,大家通常都会这样写:
public static Date getData(String date) throws ParseException {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
return sdf.parse(date);
}
public static Date getDataByFormat(String date, String format) throws ParseException {
SimpleDateFormat sdf = new SimpleDateFormat(format);
return sdf.parse(date);
}
这很简单啊,有什么争议吗?
你应该听过“时区”这个名词,大家也都知道,相同时刻不同时区的时间是不一样的。
因此在使用时间时,一定要给出时区信息。
public static void getDataByZone(String param, String format) throws ParseException {
SimpleDateFormat sdf = new SimpleDateFormat(format);
// 默认时区解析时间表示
Date date = sdf.parse(param);
System.out.println(date + ":" + date.getTime());
// 东京时区解析时间表示
sdf.setTimeZone(TimeZone.getTimeZone("Asia/Tokyo"));
Date newYorkDate = sdf.parse(param);
System.out.println(newYorkDate + ":" + newYorkDate.getTime());
}
public static void main(String[] args) throws ParseException {
getDataByZone("2023-11-10 10:00:00","yyyy-MM-dd HH:mm:ss");
}
对于当前的上海时区和纽约时区,转化为 UTC 时间戳是不同的时间。
对于同一个本地时间的表示,不同时区的人解析得到的 UTC 时间一定是不同的,反过来不同的本地时间可能对应同一个 UTC。
格式化后出现的时间错乱。
public static void getDataByZoneFormat(String param, String format) throws ParseException {
SimpleDateFormat sdf = new SimpleDateFormat(format);
Date date = sdf.parse(param);
// 默认时区格式化输出
System.out.println(new SimpleDateFormat("[yyyy-MM-dd HH:mm:ss Z]").format(date));
// 东京时区格式化输出
TimeZone.setDefault(TimeZone.getTimeZone("Asia/Tokyo"));
System.out.println(new SimpleDateFormat("[yyyy-MM-dd HH:mm:ss Z]").format(date));
}
public static void main(String[] args) throws ParseException {
getDataByZoneFormat("2023-11-10 10:00:00","yyyy-MM-dd HH:mm:ss");
}
我当前时区的 Offset(时差)是 +8 小时,对于 +9 小时的纽约,整整差了1个小时,北京早上 10 点对应早上东京 11 点。
看看Java 8是如何解决时区问题的:
Java 8 推出了新的时间日期类 ZoneId、ZoneOffset、LocalDateTime、ZonedDateTime 和 DateTimeFormatter,处理时区问题更简单清晰。
public static void getDataByZoneFormat8(String param, String format) throws ParseException {
ZoneId zone = ZoneId.of("Asia/Shanghai");
ZoneId tokyoZone = ZoneId.of("Asia/Tokyo");
ZoneId timeZone = ZoneOffset.ofHours(2);
// 格式化器
DateTimeFormatter dtf = DateTimeFormatter.ofPattern(format);
ZonedDateTime date = ZonedDateTime.of(LocalDateTime.parse(param, dtf), zone);
// withZone设置时区
DateTimeFormatter dtfz = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss Z");
System.out.println(dtfz.withZone(zone).format(date));
System.out.println(dtfz.withZone(tokyoZone).format(date));
System.out.println(dtfz.withZone(timeZone).format(date));
}
public static void main(String[] args) throws ParseException {
getDataByZoneFormat8("2023-11-10 10:00:00","yyyy-MM-dd HH:mm:ss");
}
- Asia/Shanghai对应+8,对应2023-11-10 10:00:00;
- Asia/Tokyo对应+9,对应2023-11-10 11:00:00;
- timeZone 是+2,所以对应2023-11-10 04:00:00;
在处理带时区的国际化时间问题,推荐使用jdk8的日期时间类:
- 通过ZoneId,定义时区;
- 使用ZonedDateTime保存时间;
- 通过withZone对DateTimeFormatter设置时区;
- 进行时间格式化得到本地时间;
思路比较清晰,不容易出错。
在与前端联调时,报了个错,java.lang.NumberFormatException: multiple points
,起初我以为是时间格式传的不对,仔细一看,不对啊。
百度一下,才知道是高并发情况下SimpleDateFormat有线程安全的问题。
下面通过模拟高并发,把这个问题复现一下:
public static void getDataByThread(String param, String format) throws InterruptedException {
ExecutorService threadPool = Executors.newFixedThreadPool(5);
SimpleDateFormat sdf = new SimpleDateFormat(format);
// 模拟并发环境,开启5个并发线程
for (int i = 0; i < 5; i++) {
threadPool.execute(() -> {
for (int j = 0; j < 2; j++) {
try {
System.out.println(sdf.parse(param));
} catch (ParseException e) {
System.out.println(e);
}
}
});
}
threadPool.shutdown();
threadPool.awaitTermination(1, TimeUnit.HOURS);
}
果不其然,报错。还将2023年转换成2220年,我勒个乖乖。
在时间工具类里,时间格式化,我都是这样弄的啊,没问题啊,为啥这个不行?原来是因为共用了同一个SimpleDateFormat,在工具类里,一个线程一个SimpleDateFormat,当然没问题啦!
看一下SimpleDateFormat.parse
的源码:
public class SimpleDateFormat extends DateFormat {
@Override
public Date parse(String text, ParsePosition pos){
CalendarBuilder calb = new CalendarBuilder();
Date parsedDate;
try {
parsedDate = calb.establish(calendar).getTime();
// If the year value is ambiguous,
// then the two-digit year == the default start year
if (ambiguousYear[0]) {
if (parsedDate.before(defaultCenturyStart)) {
parsedDate = calb.addYear(100).establish(calendar).getTime();
}
}
}
}
}
class CalendarBuilder {
Calendar establish(Calendar cal) {
boolean weekDate = isSet(WEEK_YEAR)
&& field[WEEK_YEAR] > field[YEAR];
if (weekDate && !cal.isWeekDateSupported()) {
// Use YEAR instead
if (!isSet(YEAR)) {
set(YEAR, field[MAX_FIELD + WEEK_YEAR]);
}
weekDate = false;
}
cal.clear();
// Set the fields from the min stamp to the max stamp so that
// the field resolution works in the Calendar.
for (int stamp = MINIMUM_USER_STAMP; stamp < nextStamp; stamp++) {
for (int index = 0; index <= maxFieldIndex; index++) {
if (field[index] == stamp) {
cal.set(index, field[MAX_FIELD + index]);
break;
}
}
}
...
}
}
- 先new CalendarBuilder();
- 通过parsedDate = calb.establish(calendar).getTime();解析时间;
- establish方法内先cal.clear(),再重新构建cal,整个操作没有加锁;
上面几步就会导致在高并发场景下,线程1正在操作一个Calendar,此时线程2又来了。线程1还没来得及处理 Calendar 就被线程2清空了。
因此,只能是一个线程一个SimpleDateFormat,也就是最常见的工具类。
🏆哪吒多年工作总结:Java学习路线总结,搬砖工逆袭Java架构师。
华为OD机试 2023B卷题库疯狂收录中,刷题点这里
刷的越多,抽中的概率越大,每一题都有详细的答题思路、详细的代码注释、样例测试,发现新题目,随时更新,全天CSDN在线答疑。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!