借助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不是线程安全的,即不提供同步机制。