丢失的8小时去哪里了?SimpleDateFormat线程不安全，多线程初始化异常解决方案

前言

本次参加了2月份的征文活动，说是对时间的处理问题，我这有2个点需要分享一下，一个是上大学的时候碰到的，还有就是在工作中遇到的由于【SimpleDateFormat线程不安全】在多线程时间初始化的时候遇到的异常问题以及解决方案。希望能为大家创造一些价值。

前言

1、丢失的8小时去哪里了

Java计算时间戳转换当前时分秒

转换成秒计算小时

2、SimpleDateFormat线程不安全，多线程初始化异常解决方案

异常复现

异常示例代码：

异常输出效果

异常源码分析

具体解决方案示例(100%解决，自己项目就这么用的)

无异常效果

总结

1、丢失的8小时去哪里了

在当年大二选修课的时候就遇到了这个问题，是时间戳转换成时间的时候，如果是自己来计算则会少了8个小时，用给定的函数就直接出来了，当时又不会配置查看源码，很苦恼，如果当时知道CSDN就好了，直接就能收到，所以当时是一直不知道为啥，后来问老师才知道的，我们今天就再来算一算，在这个分析过程中来看看具体是因为什么。

Java计算时间戳转换当前时分秒

Date date = new Date();
// 获取当前的时间戳·单位毫秒·21时15分32秒
long nowTime = date.getTime();

输出时间戳：这个时间戳的单位是毫秒。

在这里我们是根本看不出来是为啥的。接下来我们来一个一个的计算。

转换成秒计算小时

毫秒换算成秒

long second = nowTime / 1000;

换算成当前秒

long seconds = second % 60;

换算成当前分钟

long minutes = second / 60 % 60;

换算成小时

long hours = minutes / 60 % 24;

我们可以获取到：

很明显，我们计算的小时是有问题的，这个时间戳的时间是：【21时15分32秒】。可是时间换算完毕是13时，很明显21-13=8，相差8个小时，这个时候我们就很懵逼，咋回事呢？

我记得很早以前，我还只会VB语言的时候就遇到过这个问题。后来老师说，咱们是东八区我一下就明白了。

原来我们在东八区，所以我们的地区时应该在这个时间戳的基础上加上8个小时就对了。故而有以下代码：

package com.item.action;import java.util.Date;public class Main {public static void main(String[] args) {// TODO Auto-generated method stub
//      Date date = new Date();
//      // 获取当前的时间戳·单位毫秒
//      long nowTime = date.getTime();
//      System.out.println(nowTime);long nowTime = 1676985332143l;// 获取秒long second = nowTime / 1000;System.out.println(second + "s");// 获取分钟long seconds = second % 60;System.out.println(seconds + "s");long minutes = second / 60;System.out.println(minutes % 60 + "min");// 获取小时long hours = minutes / 60 % 24 + 8;System.out.println(hours + "h");System.out.println(hours+"时"+(minutes % 60)+"分"+seconds+"秒");}}

输出效果：

补上8个小时就是正确的时间了，这个类型题在蓝桥杯上也是出现过的，大家可以搜一搜，前三题，那个题目我倒是忘记了。

最后对于这个问题我们来看看百度上怎么说的：

东八区（UTC/GMT+08:00）是比世界协调时间（UTC）/格林尼治时间（GMT）快8小时的时区。

你看看，有了这句话就一下豁然开朗，我们计算的事件就是少了8个小时，所以加上就行了。

这里我找到了地区时的列表，可供大家查阅：

UTC-12: 国际日期变更线以西12小时
UTC-11: 标准时间时减去11小时
UTC-10: 标准时间时减去10小时
UTC-9: 标准时间时减去9小时
UTC-8: 标准时间时减去8小时
UTC-7: 标准时间时减去7小时
UTC-6: 标准时间时减去6小时
UTC-5: 标准时间时减去5小时
UTC-4: 标准时间时减去4小时
UTC-3: 标准时间时减去3小时
UTC-2: 标准时间时减去2小时
UTC-1: 标准时间时减去1小时
UTC: 标准时间·也就是全世界约定好的时间点
UTC+1: 标准时间时加上1小时
UTC+2: 标准时间时加上2小时
UTC+3: 标准时间时加上3小时
UTC+4: 标准时间时加上4小时
UTC+5: 标准时间时加上5小时
UTC+6: 协标准时间加上6小时
UTC+7: 标准时间时加上7小时
UTC+8: 标准时间时加上8小时
UTC+9: 标准时间时加上9小时
UTC+10: 标准时间时加上10小时
UTC+11: 标准时间时加上11小时
UTC+12: 标准时间时加上12小时

根据自己国家的地区时来进行加减就能得到自己本国的具体时间了。

2、SimpleDateFormat线程不安全，多线程初始化异常解决方案

这个问题挺坑的，只要多线程获取的时候就会格式化失败，复现代码不复杂，我就直接写了一个，并且没有进行大规模测试。

异常复现

这里直接new一个SimpleDateFormat就行，但是一定要给个static，这样就防止了各种new出现对内存的消耗

异常示例代码：

可以直接复制用来自己的测试，我没有写包名，方便大家。

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;public class Demo {/*** 项目中·为了防止无限new就设置的静态变量*/static final SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");public static Date parseToDate(String timeStr) throws ParseException {return format.parse(timeStr);}public static void main(String[] args) {// TODO Auto-generated method stub/*** 我们不多测试，仅仅小小的多线程处理，就3个。*/for (int i = 0; i < 3; i++) {new Thread() {@Overridepublic void run() {try {System.out.println(parseToDate("2023-02-23 08:25:38"));} catch (ParseException e) {// TODO Auto-generated catch blocke.printStackTrace();}}}.start();}}
}

异常输出效果

很直接的看到，第一个肯定是输出成功了的，但是后面获取的时候就出现了异常，但是它直说FOR input string输入字符串，但是我们不知道底层是啥的话很难分析为啥，所以我们得对源码进行分析一下。

异常源码分析

首先我们来看SimpDateFormat的类，能看到是直接继承了DateFormat，我们要分析的就是它们两个。

我们看看SimpDateFormat类里面重写了DateFormat中的parse函数。

代码中我们能看到【CalendarBuilder】这个对象，在1532行能看到是通过【establish】将【calendar】设置到属性中，在1537行能看到具体的操作。

calendar是父类DateFormat类的共享变量，可以被多个线程访问到

所以，当SimpleDateFormat被声明为static的时候时就是线程不安全的，多个线程同时操作，肯定会显现访问异常。

通过查看format()发现有一行calendar.setTime(date);操作的是共享变量calendar，那这么一看就很明显了——线程不安全。

具体解决方案示例(100%解决，自己项目就这么用的)

这里在解决的时候我们使用【DateTimeFormatter】来解决，但是这个类在JDK1.8之后才会有，这里声明一下，是【JAVA_JDK1.8】，【LocalDateTime】本身绝对是线程安全的，那么我们就可以直接使用它来替换，看下面的代码就能看到，但是时间的类型这里需要使用【LocalDateTime】来处理。

package test;import java.time.LocalDateTime;
import java.time.format.DateTimeFormatter;public class Demo1 {static final DateTimeFormatter dtformat = DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss");public static LocalDateTime parseToDate(String timeStr) {return LocalDateTime.parse(timeStr,dtformat);}public static void main(String[] args) {// TODO Auto-generated method stub/*** 既然我们做了处理，那么我们就来300个线程试一试<br/>* 开两个循环一个循环150次。*/for (int i = 0; i < 150; i++) {new Thread() {@Overridepublic void run() {System.out.println(parseToDate("2023-02-23 08:25:38"));}}.start();}for (int i = 0; i < 150; i++) {new Thread() {@Overridepublic void run() {System.out.println(parseToDate("2023-02-23 08:25:38"));}}.start();}}}

无异常效果

到这里，我们就彻底解决了这个项目部署的时候遇到时间初始化的问题。

希望能对初学者有一定的帮助，很多项目在初始化的时候都是要使用到时间，那么当出现问题的时候大概都是这个问题，使用我的方法就能迎刃而解了。

总结

我们初学的孩子们肯定都是在使用SimpleDateFormat来格式化时间，很少会遇到多线程的时候，所以是根本没有感觉的，但是这个bug是客观存在的，在class中我们甚至看到了开发者留的注释信息，虽然是对源码进行分析找到了原因，但是想彻底的更换固有思维逻辑还是需要一定的时间的，包括我在内，最开始在企业搞开发的时候还好，遇到大型初始化的不多，但是后来自己开始掌控项目后发现，真的有很多你开发的时候不会注意到是事情就都出现了，毕竟你已经开始统筹全局。以后遇到时间格式化的时候使用【DateTimeFormatter】来格式化，线程安全，保证不会出现这类异常了。