java 编程中 Date 与 SimpleDateFormat 时间转换不一致问题 与 SimpleDateFormat 线程安全问题
前提说明：
java.util.Date中的getTime函数定义如下：
java.util.Date代表一个时间点，其值为距公元1970年1月1日 00:00:00的毫秒数。所以它是没有时区和Locale概念的。
public long getTime() 返回自 1970 年 1 月 1 日 00:00:00 GMT 以来此 Date 对象表示的毫秒数
java中通过如下形式取得当前时间点：
|
|
而正因为其与时区的无关性，才使得我们的存储数据（如：数据库中的时间datetime类型数据）是一致的。
问题出现原因：不同时区服务器 连接统一数据库 获取时间 Date 数据是一致的，但是 由于服务器所在时区的不同，使用如下代码进行字符串转换的时候，出现不同时区服务器SimpleDateFormat转换出的字符串不一致问题。
|
|
提示：上面代码SimpleDateFormat 没有设定时区属性，会自动获取当前服务器所在时区，进行字符串的转换，进而造成时间字符串显示的不同。
解决：
|
|
另外，你可以通过如下代码修改本地时区信息：
|
|
安全问题：
JDK文档的最下面有如下说明：
SimpleDateFormat中的日期格式不是同步的。推荐（建议）为每个线程创建独立的格式实例。如果多个线程同时访问一个格式，则它必须保持外部同步。
JDK原始文档如下：
Synchronization：
Date formats are not synchronized.
It is recommended to create separate format instances for each thread.
If multiple threads access a format concurrently, it must be synchronized externally.
下面我们通过看JDK源码来看看为什么SimpleDateFormat和DateFormat类不是线程安全的真正原因：
SimpleDateFormat继承了DateFormat,在DateFormat中定义了一个protected属性的 Calendar类的对象：calendar。只是因为Calendar累的概念复杂，牵扯到时区与本地化等等，Jdk的实现中使用了成员变量来传递参数，这就造成在多线程的时候会出现错误。
在format方法里，有这样一段代码：
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;
} calendar.setTime(date)这条语句改变了calendar，稍后，calendar还会用到（在subFormat方法里），而这就是引发问题的根源。想象一下，在一个多线程环境下，有两个线程持有了同一个SimpleDateFormat的实例，分别调用format方法：
线程1调用format方法，改变了calendar这个字段。
中断来了。
线程2开始执行，它也改变了calendar。
又中断了。
线程1回来了，此时，calendar已然不是它所设的值，而是走上了线程2设计的道路。如果多个线程同时争抢calendar对象，则会出现各种问题，时间不对，线程挂死等等。
分析一下format的实现，我们不难发现，用到成员变量calendar，唯一的好处，就是在调用subFormat时，少了一个参数，却带来了这许多的问题。其实，只要在这里用一个局部变量，一路传递下去，所有问题都将迎刃而解。
这个问题背后隐藏着一个更为重要的问题--无状态：无状态方法的好处之一，就是它在各种环境下，都可以安全的调用。衡量一个方法是否是有状态的，就看它是否改动了其它的东西，比如全局变量，比如实例的字段。format方法在运行过程中改动了SimpleDateFormat的calendar字段，所以，它是有状态的。
这也同时提醒我们在开发和设计系统的时候注意下一下三点:
1.自己写公用类的时候，要对多线程调用情况下的后果在注释里进行明确说明
2.对线程环境下，对每一个共享的可变变量都要注意其线程安全性
3.我们的类和方法在做设计的时候，要尽量设计成无状态的
解决：
一：方法内 创建一个临时 SimpleDateFormat, 使用完丢弃掉：频繁创建对象消耗大，性能影响一些（推荐）。
二：维护一个SimpleDateFormat实体，转换方法上使用 Synchronized 保证线程安全：多线程堵塞（并发大系统不推荐）。
三：使用ThreadLocal : 线程独享 不堵塞，并且减少创建对象的开销（如果对性能要求比较高的情况,推荐这种方式）。
package com.peidasoft.dateformat;
import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Date;
public class ConcurrentDateUtil {
private static ThreadLocal threadLocal = new ThreadLocal() {
@Override
protected DateFormat initialValue() {
return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
}
};
public static Date parse(String dateStr) throws ParseException {
return threadLocal.get().parse(dateStr);
}
public static String format(Date date) {
return threadLocal.get().format(date);
}
}