借助SimpleDateFormat来谈谈java里的多线程不安全


SimpleDateFormat问题

程序里有一段逻辑涉及到将时间字符串转换成Date对象。昨夜系统发版,在一个定时任务频繁访问这段代码时,由于使用了静态全局的线程不安全的java.text.SimpleDateFormat对象(@link java.text.SimpleDateFormat#parse),致使出现转换异常。

简化场景,我们看下面的代码。这段代码通过多线程使用同一个SimpleDateFormat对象的parse方法, 多次执行代码来测试,可以看到会出现两种预想不到的现象,要么出现不正确的时间解析结果,要么抛出message各异的NumberFormatException异常。

 1 package jstudy.dateformat;
 2 
 3 import org.junit.Test;
 4 
 5 import java.text.ParseException;
 6 import java.text.SimpleDateFormat;
 7 import java.util.concurrent.ExecutorService;
 8 import java.util.concurrent.Executors;
 9 import java.util.concurrent.TimeUnit;
10 
11 public class TestMain {
12     SimpleDateFormat datetimeFormat = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
13 
14     @Test
15     public void testNull() throws ParseException, InterruptedException {
16         ExecutorService threadPool = Executors.newFixedThreadPool(20);
17         String startDate = "2022-01-07 15:40:15";
18         for (int i = 0; i < 20; i++) {
19             threadPool.execute(() -> {
20                 for (int j = 0; j < 20; j++) {
21 
22                     try {
23 //                        new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").parse(startDate); //使用局部变量可以避免出现线程不安全
24                         System.out.println(datetimeFormat.parse(startDate));
25                     } catch (ParseException e) {
26                         e.printStackTrace();
27                     }
28                 }
29             });
30         }
31         TimeUnit.SECONDS.sleep(3);
32     }
33 }

 如下是NumberFormatException异常信息:一种message是multiple points; 一种message是“for input string ***”;还有一种message是empty String。

Exception in thread "pool-1-thread-26" java.lang.NumberFormatException: multiple points
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1890)
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 jstudy.dateformat.TestMain.lambda$testNull$0(TestMain.java:24)

===================================================================

java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
at java.lang.Long.parseLong(Long.java:601)
at java.lang.Long.parseLong(Long.java:631)
at java.text.DigitList.getLong(DigitList.java:195)
at java.text.DecimalFormat.parse(DecimalFormat.java:2051)
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 jstudy.dateformat.TestMain.lambda$testNull$0(TestMain.java:24)

===================================================================

java.lang.NumberFormatException: For input string: "E.420222022E4"
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:1869)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
at java.text.DateFormat.parse(DateFormat.java:364)
at jstudy.dateformat.TestMain.lambda$testNull$0(TestMain.java:24)
===================================================================

java.lang.NumberFormatException: empty String
at sun.misc.FloatingDecimal.readJavaFormatString(FloatingDecimal.java:1842)
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:1869)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514)
at java.text.DateFormat.parse(DateFormat.java:364)
Tue Mar 07 15:40:15 CST 2023
Fri Jan 07 15:40:15 CST 2022
Wed Jan 07 15:15:15 CST 1
at jstudy.dateformat.TestMain.lambda$testNull$0(TestMain.java:24)

线程不安全,即多线程不安全

所谓线程不安全,指的是并发场景下多个线程同时操作同一资源时,产生的结果与预期不一致的情况。这里的操作,指的是写操作。读操作是不会出现线程不安全的。与线程不安全相对的是线程安全,多线程同时操作同一资源,与单个线程的操作结果相同,就是线程安全。

上文提到了多线程下才会存在线程安全与线程不安全的情况。所以,线程安全可以称为多线程安全,线程不安全也称为多线程不安全,这样更容易理解。

如何保证多线程下的线程安全呢?

有同学会说,自然是对共用资源进行加锁了。上面提到的java.text.SimpleDateFormat类内部就是未对资源上锁,导致当同时有多个线程使用同一个SimpleDateFormat对象时,因为线程不安全而出现计算错误或NumberFormatException。

方法很多,下面章节赘述。

多线程不安全是怎么出现的?

1).首先是并发场景下,并发场景下会同时存在多个线程(因为单线程也就不用谈线程不安全了)。

2).其次,是程序里有全局变量:类内部的全局变量,或工具类里public的静态全局变量。另一种情况是,程序里操作涉及到全局资源,如数据库表、缓存数据、磁盘文件。

3).然后,代码里引用了2)中提到的全局变量或全局资源。

4).碰巧,2)中提到的全局变量的class内部没有采用加锁机制;或者,程序在使用2)中提到的全局变量或全局资源时也未做加锁处理。

如何规避多线程不安全(如何保证多线程安全)

问题即答案!

a)不共用全局变量。各线程各自new自己的对象,使用局部变量。

b)共用全局变量的话,可以借助ThreadLocal来实现每个线程自己的副本。

b)线程同步。

b1)共用全局变量时,使用加锁处理来保证操作的同步性,即,同时只允许一个线程来操作共享资源。可以借助悲观的synchronized锁,或乐观的可重入锁j.u.c.locks.ReentrantLock。

    • synchronized修饰表示代码块同步,synchronized修饰方法表示方法同步。
    • ReentrantLock实现j.u.c.locks.Lock接口,它更灵活,分离了读操作和写操作,即允许同时多个线程读和只有一个线程写。

b2)对于数据库数据的操作,除了b1)提到的程序加锁外,还可以借助数据库里的悲观锁,如mysql的for update。当然,这种悲观锁会降低程序执行效率,所以,也可以通过程序实现乐观锁来控制,常见的乐观锁是使用版本号、状态锁。

b3)对于分布式系统来说,要使用分布式锁来保证不同进程的线程同步,分布式锁可以使用Redis自旋等待来实现,或使用Redisson分布式锁。

c)改用线程安全的类对象,即使用不可变的类对象。例如,使用java.time.format.DateTimeFormatter替代java.text.SimpleDateFormat;使用j.u.c.atomic.AtomicInteger替代java.langInteger;使用java.lang.StringBuffer替代java.lang.StringBuilder。 

  • DateTimeFormatter的javadoc上写的很直白:This class is immutable and thread-safe.(这个类是不可变的,并且是线程安全的)。
  • 同样,StringBuilder类里也明确写着:StringBuilder是一个可变的(mutable)字符序列。Instances of {@code StringBuilder} are not safe for use by multiple threads. If such synchronization is required then it is recommended that {@link java.lang.StringBuffer} be used.---StringBuilder实例是多线程不安全的,如果在需要保证线程同步的场景下就要使用StringBuffer来替代。  当然了,我们通常不会在代码里放一个全局的StringBuffer来操作字符串拼接。所以,在方法内部的话,还是推荐用StringBuilder,因为StringBuilder更faster。
  • Hashtable是线程安全的,即Hashtable的方法都提供了同步机制;HashMap不是线程安全的,即不提供同步机制。