提供了编程的基础技术教程

zl程序教程

您现在的位置是：首页 >  后端

当前栏目

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

多线程安全异常线程解决方案 初始化 小时 丢失
2023-09-14 09:05:00 时间

前言

本次参加了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() {
				@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】来格式化，线程安全，保证不会出现这类异常了。

相关文章