問題描述

下面代碼里無鎖和有鎖比是更好的實現(xiàn)嗎？我用jmeter每秒20個請求，無鎖代碼執(zhí)行test()里的sleep操作的輸出大部分與500毫秒差別巨大，而有鎖代碼的輸出基本就是500毫秒相差1，2毫秒的樣子，這個問題很怪異啊....

@Controller@RequestMapping('/bench/')public class BenchController { @Autowired private FlowService flowService; private static Object[] lockObj; private static AtomicReference<Integer>[] locks; static {lockObj = new Object[100];for (int i = 0; i < lockObj.length; i++) { lockObj[i] = new Object();}locks = new AtomicReference[100];for (int i = 0; i < locks.length; i++) { locks[i] = new AtomicReference<Integer>(null);} } @RequestMapping('a') @ResponseBody public long a(int id) throws Exception {long start = System.currentTimeMillis();int index = id % 100;long inner=0;synchronized (lockObj[index]) { inner=test();}long result = System.currentTimeMillis() - start;System.out.println('all: '+result+' inner: '+inner);return result; } @RequestMapping('b') @ResponseBody public long b(int id) throws Exception {long start = System.currentTimeMillis();AtomicReference<Integer> lock=locks[id % 100];while (!lock.compareAndSet(null, id)) {}long inner=test();boolean flag=lock.compareAndSet(id, null);long result = System.currentTimeMillis() - start;System.out.println('all: '+result+' inner: '+inner+' flag:'+flag);return result; } public long test()throws Exception{long innerstart = System.currentTimeMillis();Thread.sleep(500);System.out.println(System.currentTimeMillis()-innerstart);return System.currentTimeMillis()-innerstart; }}

問題解答

1.首先，明確兩個問題，synchronized 一般不是跟AtomicXX類進(jìn)行比較，更多的是跟ReentrantLock這個類進(jìn)行比較,網(wǎng)上關(guān)于這2者的比較很多，可以自行g(shù)oogle之。

2.問題中關(guān)于無鎖跟有鎖的疑問，測試代碼b中的代碼是有問題的，

對于方法a,synchronized代碼塊來說，鎖被第一個進(jìn)來的線程持有后，后續(xù)線程請求獲取鎖會被阻塞掛起，直到前面一個線程釋放鎖，后續(xù)的線程會恢復(fù)執(zhí)行，由于鎖的存在，20個請求類似于順序執(zhí)行，這一層由jvm調(diào)度

對于方法b,cas操作是非阻塞的，方法中的while循環(huán)其實是一直在執(zhí)行(不斷嘗試進(jìn)行cas操作),而我們知道，死循環(huán)是會消耗cpu資源的，并發(fā)數(shù)越多，線程越多，此處的cas操作越多，必然導(dǎo)致cpu使用率飆升，方法b中的代碼由jmeter測試的時候理論上來說應(yīng)該一直由20個活躍的工作線程存在，cpu與線程模型是另外一個話題，線程數(shù)的調(diào)優(yōu)是jvm一個比較高級的話題，感興趣可以自行g(shù)oogle之

說說ReentrantLock與synchronized:通常情況下在高并發(fā)下，ReentrantLock比synchronized擁有更好的性能，而且ReentrantLock提供來一些synchronized并不提供的功能(鎖超時自動放棄等)，示例代碼中可以減少sleep的時間，從而模擬更短停頓，更高的并發(fā)，500ms對于人來說很短，對于cpu來說基本就是天文數(shù)字了，基本用“慢如蝸牛”來形容也不為過,修改類一下示例代碼:

package com.gzs.learn.springboot;import java.util.LinkedList;import java.util.Random;import java.util.concurrent.atomic.AtomicReference;import java.util.concurrent.locks.LockSupport;import java.util.concurrent.locks.ReentrantLock;import org.springframework.stereotype.Controller;import org.springframework.web.bind.annotation.PathVariable;import org.springframework.web.bind.annotation.RequestMapping;import org.springframework.web.bind.annotation.ResponseBody;@Controller@RequestMapping('/bench/')public class BenchController { private Random random = new Random(); private static Object[] lockObj; private static AtomicReference<Integer>[] locks; private static ReentrantLock[] reentrantLocks; static {lockObj = new Object[100];for (int i = 0; i < lockObj.length; i++) { lockObj[i] = new Object();}locks = new AtomicReference[100];for (int i = 0; i < locks.length; i++) { locks[i] = new AtomicReference<Integer>(null);}reentrantLocks = new ReentrantLock[100];for (int i = 0; i < reentrantLocks.length; i++) { reentrantLocks[i] = new ReentrantLock();} } @RequestMapping('a/{id}') @ResponseBody public long a(@PathVariable('id') int id) throws Exception {long start = System.currentTimeMillis();int index = id % 100;long inner = 0;synchronized (lockObj[index]) { inner = test();}long result = System.currentTimeMillis() - start;System.out.println('all: ' + result + ' inner: ' + inner);return result; } @RequestMapping('b/{id}') @ResponseBody public long b(@PathVariable('id') int id) throws Exception {long start = System.currentTimeMillis();id = id % 100;AtomicReference<Integer> lock = locks[id];int b = 0;while (!lock.compareAndSet(null, id)) { b = 1 + 1;}long inner = test();boolean flag = lock.compareAndSet(id, null);long result = System.currentTimeMillis() - start;System.out.println('all: ' + result + ' inner: ' + inner + ' flag:' + flag);System.out.println(b);return result; } @RequestMapping('c/{id}') @ResponseBody public long c(@PathVariable('id') int id) throws Exception {long start = System.currentTimeMillis();id = id % 100;ReentrantLock lock = reentrantLocks[id];lock.lock();long inner = test();lock.unlock();long result = System.currentTimeMillis() - start;System.out.println('all: ' + result + ' inner: ' + inner);return result; } public long test() throws Exception {long innerstart = System.currentTimeMillis();Thread.sleep(0, 100);// Thread.sleep(500);System.out.println(System.currentTimeMillis() - innerstart);return System.currentTimeMillis() - innerstart; }}

方法c是用ReentrantLock實現(xiàn)的，絕大多少情況下ReentrantLock比synchronized高效

juc(java.util.concurrent)中的核心類Aqs(AbstractQueuedSynchronizer)是一個基于隊列的 并發(fā)包，默認(rèn)線程在鎖競爭(自旋)超過1000納秒的時候會被park(掛起操作),從而減少cpu頻繁的線程切換，可以嘗試調(diào)整方法c中的sleep的時間參數(shù)。

測試方法，本機(jī)沒有裝jmeter，用apache ab做的測試，測試命令:

ab -n 100 -c 20 http://localhost:8080/bench/a/10