写了这么多年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 点。云南idc服务商

看看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() {

        @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，还是有一定道理的。