从Java5开始添加的一个提供各种并发编程方法的类java.util.concurrent，可以模拟并发请求，进行压测或者测试方法是否线程安全。

最近遇到一个bug，之前线上正常运行了几个月的接口突然出现偶尔失败的情况，查日志发现接口生成的签名错误，而且都是在有并发请求时出错。检查了签名生成逻辑和线程安全感觉没有问题，于是就想在本地模拟一下并发跟一下代码寻找问题。

首先看一下签名生成方法，其中使用到的 StringBuffer 是线程安全的，其它的地方咋一看好像也没有什么问题。到底问题出在什么地方下面我们测一下就知道了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public static String getSignature(SortedMap<Object, Object> parameters, String key) {
	StringBuffer sb = new StringBuffer();
    Set<Entry<Object, Object>> es = parameters.entrySet();
    Iterator<Entry<Object, Object>> it = es.iterator();
    while (it.hasNext()) {
        @SuppressWarnings("rawtypes")
        Map.Entry entry = (Map.Entry) it.next();
        String k = (String) entry.getKey();
        Object v = entry.getValue();
        if (null != v && !"".equals(v)) {
            sb.append(k + "=" + v + "&");
        }
    }
    sb.append("key=" + key);
    String sign = MD5Util.getMD5String(sb.toString()).toUpperCase();
    return sign;
}

java.util.concurrent 包含许多线程安全、测试良好、高性能的并发构建块。其中CountdownLatch类是对已经在它们中间分摊了问题的一组线程进行协调，CountdownLatch 将到达和等待功能分离。任何线程都可以通过调用 countDown() 减少当前计数，这种不会阻塞线程，而只是减少计数。调用 await() 任何线程都会被阻塞，直到闩锁计数减少为零，在该点等待的所有线程才被释放。当问题已经分解为许多部分，每个线程都被分配一部分计算时，CountdownLatch 非常有用。在工作线程结束时，它们将减少计数，协调线程可以在闩锁处等待当前这一批计算结束，然后继续移至下一批计算。具有计数1的 CountdownLatch 可以用作”启动大门”，来立即启动一组线程；工作线程可以在闩锁处等待，协调线程减少计数，从而立即释放所有工作线程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
public static void main(String[] args) {
	
	final CountDownLatch begin = new CountDownLatch(1); //为0时开始执行
	final ExecutorService exec = Executors.newFixedThreadPool(9);
	
	for (int i = 0; i < 9; i++) {
		final int NO = i + 1;
		Runnable runnable = new Runnable() {
			@Override
			public void run() {
				try {
					begin.await(); //等待直到 CountDownLatch减到1
			    	SortedMap<Object, Object> sortedMap = new TreeMap<Object, Object>();
			    	//----------签名参数------------
			    	sortedMap.put("appid", "5412916052207510000052159");
			    	sortedMap.put("mch_id", "dhfkjadh");
			    	sortedMap.put("nonce_str", "fasjkldfh");
			    	String sign = getSignature(sortedMap,"fhldhfkajhdfkjajsdh");
					System.out.println("sign"+String.valueOf(NO)+": "+sign);
				} catch (Exception e) {
					e.printStackTrace();
				}
			}
		};
		exec.submit(runnable); 
	}
	System.out.println("开始执行");    
    begin.countDown(); // begin减一，开始并发执行  
    exec.shutdown();      
}

以上代码只模拟了9个并发线程，运行得到9次签名生成结果如下，参数不变的情况下计算结果各不相同，那显然就是方法存在线程安全问题了。

开始执行
sign5: 35F6B4BE2E33D3A655210599E5C57936
sign6: F4B678751A3C071B25AD2AB08CED2027
sign8: F4B678751A3C071B25AD2AB08CED2027
sign3: E8A83555C457502AAEDF379E38DC6233
sign9: 8568FA9C6E5C1CE1A1DD5C22D82D013B
sign2: 37EE9EA8D1CBA2B3F094FDAC1E565288
sign4: 35F6B4BE2E33D3A655210599E5C57936
sign1: E86DA0FF3270A381146135F24CEBFB3D
sign7: F486A648860192E312B7D2BA26411049

这时我注意到签名方法里使用了 MD5Util.getMD5String() 的方法，单独给这个MD5方法加上synchronized同步后运行得到如下结果：

开始执行
sign8: F4B678751A3C071B25AD2AB08CED2027
sign4: F4B678751A3C071B25AD2AB08CED2027
sign7: F4B678751A3C071B25AD2AB08CED2027
sign9: F4B678751A3C071B25AD2AB08CED2027
sign2: F4B678751A3C071B25AD2AB08CED2027
sign5: F4B678751A3C071B25AD2AB08CED2027
sign3: F4B678751A3C071B25AD2AB08CED2027
sign1: F4B678751A3C071B25AD2AB08CED2027
sign6: F4B678751A3C071B25AD2AB08CED2027

看来就是这个方法的问题了，跟进去研究一下，发现计算消息摘要的类 MessageDigest 为static，也就是每次方法调用都使用的是同一个对象，而这个类是非线程安全的（参考）

The MessageDigest classes are NOT thread safe. If they’re going to be used by different threads, just create a new one, instead of trying to reuse them.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
protected static MessageDigest messagedigest = null;

static {
    try {
        messagedigest = MessageDigest.getInstance("MD5");
    } catch (NoSuchAlgorithmException nsaex) {
        nsaex.printStackTrace();
    }
}

//... 省略 ...

public static String getMD5String(String s) {
    return getMD5String(s.getBytes());
}

public static String getMD5String(byte[] bytes) {
	messagedigest.update(bytes);
    return bufferToHex(messagedigest.digest());
}

对于这个问题有一些解决方法，最容易想到的就是我们常用的 synchronized 同步块，在资源竞争不是很激烈的情况下，偶尔会有同步的情形下，synchronized是很合适的，当同步非常激烈的时候，synchronized的性能则会急剧下降。而在这里我们采用上文建议的方法，在 MD5Util 中每个使用 MessageDigest 的方法里都创建一个新的对象即可，修改后的代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public static String getMD5String(String s) {
    return getMD5String(s.getBytes());
}

public static String getMD5String(byte[] bytes) {
	MessageDigest messagedigest = null;
	try {
		messagedigest = MessageDigest.getInstance("MD5");
		messagedigest.update(bytes);
    } catch (NoSuchAlgorithmException nsaex) {
    	nsaex.printStackTrace();
    }
    return bufferToHex(messagedigest.digest());
}

类似的问题也会出现在SimpleDateFormat（包括DateFormat）类的format()和parse()上，因为该类中的成员变量calendar会进行calendar.setTime(date)及calendar.clear()方法改变其状态，这时候多线程下便会出现线程不一致的情况。由于format()方法只用到的setTime方法，因此多线程下会出现时间不一致的情况，但是不会抛异常，这个问题比较隐蔽。而parse方法即用到了setTime也用到了clear方法，多线程时b线程设置了date这时候a线程又调用了clear方法清空了值，这是b线程再继续执行便会抛出异常。

对SimpleDateFormat和DateFormat的使用可以参考这篇文章深入理解Java：SimpleDateFormat安全的时间格式化

第一次碰到java并发的问题，解决的过程中查询了很多资料发现对java多线程了解的很少，后面找时间系统的研究一下关于java多线程的知识点。

References

[1] Message Digest
[2] java模拟并发访问
[3] java.util.concurrent介绍
[4] Java Concurrency / Multithreading Tutorial