龙空技术网

SimpleDateFormat为什么是线程不安全的?

哪吒编程 162

前言:

今天各位老铁们对“js date format”大体比较着重,各位老铁们都需要剖析一些“js date format”的相关文章。那么小编在网络上汇集了一些有关“js date format””的相关资讯,希望大家能喜欢,大家一起来了解一下吧!

大家好,我是哪吒。

在日常开发中,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,当然没问题啦!

可以通过TreadLocal 局部变量,解决SimpleDateFormat的线程安全问题。

public static void getDataByThreadLocal(String time, String format) throws InterruptedException {    ExecutorService threadPool = Executors.newFixedThreadPool(5);    ThreadLocal<SimpleDateFormat> sdf = new ThreadLocal<SimpleDateFormat>() {        @Override        protected SimpleDateFormat initialValue() {            return 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.get().parse(time));                } catch (ParseException e) {                    System.out.println(e);                }            }        });    }    threadPool.shutdown();    threadPool.awaitTermination(1, TimeUnit.HOURS);}
看一下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清空了。

因此,通过编写Date工具类,一个线程一个SimpleDateFormat,还是有一定道理的。

标签: #js date format