前言
本次参加了2月份的征文活动，说是对时间的处理问题，我这有2个点需要分享一下，一个是上大学的时候碰到的，还有就是在工作中遇到的由于【SimpleDateFormat线程不安全】在多线程时间初始化的时候遇到的异常问题以及解决方案。希望能为大家创造一些价值。
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() { @Override public void run() { try { System.out.println(parseToDate("2023-02-23 08:25:38")); } catch (ParseException e) { // TODO Auto-generated catch block e.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() { @Override public void run() { System.out.println(parseToDate("2023-02-23 08:25:38")); } }.start(); } for (int i = 0; i < 150; i++) { new Thread() { @Override public void run() { System.out.println(parseToDate("2023-02-23 08:25:38")); } }.start(); } } }
无异常效果
到这里，我们就彻底解决了这个项目部署的时候遇到时间初始化的问题。
希望能对初学者有一定的帮助，很多项目在初始化的时候都是要使用到时间，那么当出现问题的时候大概都是这个问题，使用我的方法就能迎刃而解了。
总结
我们初学的孩子们肯定都是在使用SimpleDateFormat来格式化时间，很少会遇到多线程的时候，所以是根本没有感觉的，但是这个bug是客观存在的，在class中我们甚至看到了开发者留的注释信息，虽然是对源码进行分析找到了原因，但是想彻底的更换固有思维逻辑还是需要一定的时间的，包括我在内，最开始在企业搞开发的时候还好，遇到大型初始化的不多，但是后来自己开始掌控项目后发现，真的有很多你开发的时候不会注意到是事情就都出现了，毕竟你已经开始统筹全局。以后遇到时间格式化的时候使用【DateTimeFormatter】来格式化，线程安全，保证不会出现这类异常了。
