SimpleDateFormat——从入门到跑路
我们都是做开发的，对时间相关类SimpleDateFormat都不陌生，不管是时间的格式化输出和解析，还是生成uuid都有被用到过。
想必大家大多是这样用的：
public class SimpleDateFormatTest {
private static final java.text.SimpleDateFormat sdf = new java.text.SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static void main(String[] args) throws InterruptedException {
System.out.println(sdf.format(new Date()));
}
}
今天收到粉丝的求助，说工作中用到SimpleDateFormat的知识，但写完的代码在多线中使用一直报错。
得知情况后我们便征求粉丝同意，要来了部分代码，帮忙解决这个问题。
在经过稍微调整后，写了一个demo，如下：
public class SimpleDateFormatTest {
private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static class ParseDate implements Runnable {
int i = 0;
public ParseDate(int i) {
this.i = i;
}
@Override
public void run() {
try {
Date date = sdf.parse("2020-9-10 12:00:" + i % 60);
System.out.println("date: " + date);
} catch (Exception e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) throws InterruptedException {
ExecutorService exec = Executors.newFixedThreadPool(10);
for (int i = 0; i < 1000; i++) {
exec.execute(new ParseDate(i));
}
}
}
看上去没有错误的代码一运行起来却报出一大堆异常。
经过分析，报错主要是因为SimpleDateFormat并非线程安全的。
在源码中我们得知SimpleDateFormat内部维护了一个Calender对象，用于格式化日期。因此在多线程环境下，多个线程就会使用同一个Calender对象格式化日期，导致数据竞争，最后出现异常。
所以我们对代码进行优化，首先想到的就是上同步锁：
public class SimpleDateFormatTest {
private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static class ParseDate implements Runnable {
int i = 0;
public ParseDate(int i) {
this.i = i;
}
@Override
public void run() {
try {
Date date = sdf.parse("2020-9-10 12:00:" + i % 60);
System.out.println("date: " + date);
} catch (Exception e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) throws InterruptedException {
ExecutorService exec = Executors.newFixedThreadPool(10);
for (int i = 0; i < 1000; i++) {
exec.execute(new ParseDate(i));
}
}
}
上了锁之后，运行一次发现没有问题了。
但是我们都知道，在高并发的情况下synchronized锁不是一个很好的解决方案。
为了不留隐患的彻底解决这个问题，我们得想一个更好的办法来继续优化。
仔细思考过后，我们很快发现：如果每次使用的时候new一个SimpleDateFormat的实例，这样可以保证每个实例使用自己的Calendar实例。
public class SimpleDateFormatTest {
private static final SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
public static class ParseDate implements Runnable {
int i = 0;
public ParseDate(int i) {
this.i = i;
}
@Override
public void run() {
try {
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
Date date = sdf.parse("2020-9-10 12:00:" + i % 60);
System.out.println("date: " + date);
} catch (ParseException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) throws InterruptedException {
ExecutorService exec = Executors.newFixedThreadPool(10);
for (int i = 0; i < 1000; i++) {
exec.execute(new ParseDate(i));
}
}
}
优秀的大家应该已经发现了，这样修改之后每次使用都需要new一个对象，并且使用后由于没有其它引用，对象需要被回收，整个过程的开销不小。
因此，我们可以进一步进行优化。
既然每次使用都需要new一个对象，那我们不妨使用ThreadLocal去解决这个问题，令每个线程创建一个当前线程的SimpleDateFormat的实例对象。
public class SimpleDateFormatTest {
private static final ThreadLocal<SimpleDateFormat> threadLocal = new ThreadLocal<>();
public static class ParseDate implements Runnable {
int i = 0;
public ParseDate(int i) {
this.i = i;
}
@Override
public void run() {
try {
if(threadLocal.get() == null) {
threadLocal.set(new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"));
}
Date date = threadLocal.get().parse("2020-9-10 12:00:" + i % 60);
System.out.println("date: " + date);
} catch (ParseException e) {
e.printStackTrace();
}
}
}
public static void main(String[] args) throws InterruptedException {
ExecutorService exec = Executors.newFixedThreadPool(10);
for (int i = 0; i < 1000; i++) {
exec.execute(new ParseDate(i));
}
}
}
运行无误，很好的解决了这个粉丝的问题。
回顾整个解决过程，在解决多线程并发问题上同步锁跟ThreadLocal思路相似，但是ThreadLocal并不能替代同步机制，两者面向的问题领域不同。
同步机制是解决多个线程对相同资源的并发访问，多个线程之间进行通信等问题的有效方式。
而ThreadLocal是隔离多个线程的数据共享，从根本上就不在多个线程之间共享资源，这样当然不需要对多个线程进行同步了。
为每一个线程维护一个和该线程绑定的变量的副本，从而隔离了多个线程的数据，每一个线程都拥有自己的变量副本，从而也就没有必要对该变量进行同步了。
写在最后：
我们在写代码的时候可以多去想一步，去想想为什么，是不是有其他更好的办法，也许只是换一种思路，一个小小的改动，便会有完全不一样的结果。
代码的优化也不限于让性能得到显著提升，有些代码的重构可以让其可读性、可扩展性得到很大的一个提升，这也属于一种优化。
看到这里的你如果也有亟待解决的问题，欢迎留言，我们会在第一时间提供解决思路与办法。
