SimpleDateFormat是Java中非常常见的一个类,用来解析和格式化日期字符串。但是SimpleDateFormat在多线程的环境并不是安全的,这个是很容易犯错的部分,接下来讲一下这个问题出现的过程以及解决的思路。

问题描述:
先看代码,用来获取一个月的天数的:

import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date; public class DateUtil { /**
* 获取月份天数
* @param time 201202
* @return
*/
public static int getDays(String time) throws Exception {
// String time = "201202";
SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM");
Date date = sdf.parse(time);
Calendar c = Calendar.getInstance();
c.setTime(date);
int day = c.getActualMaximum(Calendar.DATE);
return day;
} }

可以看到在这个方法里,每次要获取值的时候就先要创建一个SimpleDateFormat的实例,频繁调用这个方法的情况下很耗性能。为了避免大量实例的频繁创建和销毁,我们通常会使用单例模式或者静态变量进行改造,一般会这么改:

import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date; public class DateUtil { private static SimpleDateFormat sdf = new SimpleDateFormat("yyyyMM"); /**
* 获取月份天数
* @param time 201202
* @return
*/
public static int getDays(String time) throws Exception {
// String time = "201202";
Date date = sdf.parse(time);
Calendar c = Calendar.getInstance();
c.setTime(date);
int day = c.getActualMaximum(Calendar.DATE);
return day;
} }

此时不管调用多少次这个方法,java虚拟机里只有一个SimpleDateFormat对象,效率和性能肯定要比第一个方法好,这个也是很多程序员选择的方法。但是,在这个多线程的条件下,多个thread共享同一个SimpleDateFormat,而SimpleDateFormat本身又是线程非安全的,这样就很容易出各种问题。

验证问题:
用一个简单的例子验证一下多线程环境下SimpleDateFormat的运行结果:

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
import java.util.concurrent.CountDownLatch; public class DateUtil {
private static SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); public static String format(Date date) {
return dateFormat.format(date);
} public static Date parse(String dateStr) throws ParseException {
return dateFormat.parse(dateStr);
} public static void main(String[] args) {
final CountDownLatch latch = new CountDownLatch(1);
final String[] strs = new String[] {"2016-01-01 10:24:00", "2016-01-02 20:48:00", "2016-01-11 12:24:00"};
for (int i = 0; i < 10; i++) {
new Thread(new Runnable() {
@Override
public void run() {
try {
latch.await();
} catch (InterruptedException e) {
e.printStackTrace();
} for (int i = 0; i < 10; i++){
try {
System.out.println(Thread.currentThread().getName()+ "\t" + parse(strs[i % strs.length]));
Thread.sleep(100);
} catch (ParseException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}).start();
}
latch.countDown();
}
}

看一下运行的结果:

Thread-9    Fri Jan 01 10:24:00 CST 2016
Thread-1 Sat Feb 25 00:48:00 CST 20162017
Thread-5 Sat Feb 25 00:48:00 CST 20162017
Exception in thread "Thread-4" Exception in thread "Thread-6" java.lang.NumberFormatException: For input string: "2002.E20022E"
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:2043)
at sun.misc.FloatingDecimal.parseDouble(FloatingDecimal.java:110)
at java.lang.Double.parseDouble(Double.java:538)
at java.text.DigitList.getDouble(DigitList.java:169)
at java.text.DecimalFormat.parse(DecimalFormat.java:2056)
at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2162)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
at java.text.DateFormat.parse(DateFormat.java:364)
at DateUtil.parse(DateUtil.java:24)
at DateUtil$2.run(DateUtil.java:45)

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

查找问题:

首先看一下SimpleDateFormat的源码:

private StringBuffer format(Date date, StringBuffer toAppendTo,
FieldDelegate delegate) {
// Convert input date to time field list
calendar.setTime(date); boolean useDateFormatSymbols = useDateFormatSymbols(); for (int i = 0; i < compiledPattern.length; ) {
int tag = compiledPattern[i] >>> 8;
int count = compiledPattern[i++] & 0xff;
if (count == 255) {
count = compiledPattern[i++] << 16;
count |= compiledPattern[i++];
} switch (tag) {
case TAG_QUOTE_ASCII_CHAR:
toAppendTo.append((char)count);
break; case TAG_QUOTE_CHARS:
toAppendTo.append(compiledPattern, i, count);
i += count;
break; default:
subFormat(tag, count, delegate, toAppendTo, useDateFormatSymbols);
break;
}
}
return toAppendTo;
}

可以看到format()方法先将日期存放到一个Calendar对象中,而这个Calendar在SimpleDateFormat中是以成员变量的形式存在的。随后调用subFormat()时会再次用到成员变量Calendar。这就是问题所在。同样,在parse()方法里也会存在相应的问题。
试想,在多线程环境下,如果两个线程都使用同一个SimpleDateFormat实例,那么就有可能存在其中一个线程修改了calendar后紧接着另一个线程也修改了calendar,那么随后第一个线程用到calendar时已经不是它所期待的值了。

避免问题:

那么,如何保证SimpleDateFormat的线程安全呢?
1.每次使用SimpleDateFormat时都创建一个局部的SimpleDateFormat对象,跟一开始的那个方法一样,但是存在性能上的问题,开销较大。
2.加锁或者同步

import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date; public class DateSyncUtil { private static SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); public static String formatDate(Date date)throws ParseException{
synchronized(sdf){
return sdf.format(date);
}
} public static Date parse(String strDate) throws ParseException{
synchronized(sdf){
return sdf.parse(strDate);
}
}
}

当线程较多时,当一个线程调用该方法时,其他想要调用此方法的线程就要block,多线程并发量大的时候会对性能有一定的影响。
3.使用ThreadLocal

public class DateUtil {
private static ThreadLocal<SimpleDateFormat> local = new ThreadLocal<SimpleDateFormat>() {
@Override
protected SimpleDateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
}
}; public static String format(Date date) {
return local.get().format(date);
} public static Date parse(String dateStr) throws ParseException {
return local.get().parse(dateStr);
}
}

使用ThreadLocal可以确保每个线程都可以得到一个单独的SimpleDateFormat对象,既避免了频繁创建对象,也避免了多线程的竞争。

SimpleDateFormat,Calendar 线程非安全的问题的更多相关文章

  1. JDK中的SimpleDateFormat线程非安全

    在JDK中使用SimpleDateFormat的时候都会遇到线程安全的问题,在JDK文档中也说明了该类是线程非安全的,建议对于每个线程都创建一个SimpleDateFormat对象.如下面一个Case ...

  2. 如何在一个线程环境中使用一个线程非安全的java类

    在开发过程中 当我们拿到一个线程非安全的java类的时候,我们可以额外创建这个类的管理类 并在管理类中控制同步 比如 一个非线程安全的Pair类 package test.thread.sx.test ...

  3. 06_java 时间获取练习_Date\SimpleDateFormat\Calendar类练习

     1.获取当前的日期,并把这个日期转换为指定格式的字符串,如2088-08-08 08:08:08 import java.text.SimpleDateFormat; import java.uti ...

  4. 时间获取_Date\SimpleDateFormat\Calendar类

     1.获取当前的日期,并把这个日期转换为指定格式的字符串,如2088-08-08 08:08:08 import java.text.SimpleDateFormat; import java.uti ...

  5. java基础1.5版后新特性 自动装箱拆箱 Date SimpleDateFormat Calendar.getInstance()获得一个日历对象 抽象不要生成对象 get set add System.arrayCopy()用于集合等的扩容

    8种基本数据类型的8种包装类 byte Byte short Short int Integer long Long float Float double Double char Character ...

  6. Java基础 与时间日期相关的类:System -Date -SimpleDateFormat -Calendar类 -解决后缀.000Z 的时区问题

    笔记总结: /**与时间相关的类:System_Date_SimpleDateFormat_Calendar类 * 1.system 类下的currentTimeMillis() * 输出从1970年 ...

  7. session/SessionFactory线程非安全和线程安全

    SessionFactory负责创建session,SessionFactory是线程安全的,多个并发线程可以同时访问一个 SessionFactory 并从中获取Session实例. (Sessio ...

  8. ios专题 - 多线程非GCD(1)

    iOS多线程初体验是本文要介绍的内容,iPhone中的线程应用并不是无节制的,官方给出的资料显示iPhone OS下的主线程的堆栈大小是1M,第二个线程开始都是512KB.并且该值不能通过编译器开关或 ...

  9. 【源码】HashMap源码及线程非安全分析

    最近工作不是太忙,准备再读读一些源码,想来想去,还是先从JDK的源码读起吧,毕竟很久不去读了,很多东西都生疏了.当然,还是先从炙手可热的HashMap,每次读都会有一些收获.当然,JDK8对HashM ...

随机推荐

  1. ethereumjs/ethereumjs-blockchain-2-test

    https://github.com/ethereumjs/ethereumjs-blockchain/tree/master/test 'use strict' const test = requi ...

  2. JSTL的下载和配置

    1,首先在输入网址http://www.oracle.com/technetwork/java/jstl-137486.html 2,单击红色图标所示 3,单击Download 4,单击JSTL Im ...

  3. Tomcat中Pipeline

    Pipeline 节选部分源码.源码版本 Tomcat8.5 处理模式 Pipeline--Valve是一种责任链模式,它和普通责任链模式有两点区别: 每个Pipeline都是有特定的Valve,而且 ...

  4. Epoll为我们带来了什么

    libevent中用到的,epoll是Linux下多路复用IO接口select/poll的增强版本.网上找到的介绍资料,无法标明来源. Q:网络服务器的瓶颈在哪? A:IO效率. 在大家苦苦的为在线人 ...

  5. Python中获取异常(try Exception)信息

    异常信息的获取对于程序的调试非常重要,可以有助于快速定位有错误程序语句的位置. 这里获取异常(Exception)信息采用try...except...程序结构.如下所示: try: ... exce ...

  6. Java单例模式几种实现方式

    在平时的工作.学员的学习以及面试过程中,单例模式作为一种常用的设计模式,会经常被面试官问到,甚至笔试会要求学员现场默写,下面将会就单例模式的实现思路和几种常见的实现方式进行简单的分享. 单例模式,是一 ...

  7. 默认情况下eth0网卡配置文件路径及客户端DNS的路径

    默认情况下eth0网卡配置文件路径及客户端DNS的路径? eth0 网卡配置文件路径如下: /etc/sysconfig/network-scripts/ifcfg-eth0 客户端DNS的路径如下: ...

  8. html-头标签的使用

    HTML两部分组成 head和body ** 在head里面的标签就是头标签 ** title标签:表示在标签上显示的内容 ** meta标签:设置页面的一些相关内容(用的比较少) <meta ...

  9. PHP实现验证码功能

    原文链接:http://www.qqdeveloper.com/a/54.html 什么是验证码? 借用百度的解释:验证码这个词最早是在2002年由卡内基梅隆大学的路易斯·冯·安.Manuel Blu ...

  10. 小白该如何学习Linux操作系统

    一. 选择适合自己的Linux发行版 谈到linux的发行版别,太多了,可能谁也不能给出一个准确的数字,但是有一点是能够必定的,linux正在变得越来越盛行, 面临这么多的Linux 发行版,打算从别 ...