大家使用多線程無(wú)非是為了提高性能,但如果多線程使用不當(dāng),不但性能提升不明顯,而且會(huì)使得資源消耗更大。下面列舉一下可能會(huì)造成多線程性能問(wèn)題的點(diǎn):
- 死鎖
- 過(guò)多串行化
- 過(guò)多鎖競(jìng)爭(zhēng)
- 切換上下文
- 內(nèi)存同步
下面分別解析以上性能隱患
死鎖
關(guān)于死鎖,我們?cè)趯W(xué)習(xí)操作系統(tǒng)的時(shí)候就知道它產(chǎn)生的原因和危害,這里就不從原理上去累述了,可以從下面的代碼和圖示重溫一下死鎖產(chǎn)生的原因:
- public class LeftRightDeadlock {
- private final Object left = new Object();
- private final Object right = new Object();
- public void leftRight() {
- synchronized (left) {
- synchronized (right) {
- doSomething();
- }
- }
- }
- public void rightLeft() {
- synchronized (right) {
- synchronized (left) {
- doSomethingElse();
- }
- }
- }
- }

預(yù)防和處理死鎖的方法:
1)盡量不要在釋放鎖之前競(jìng)爭(zhēng)其他鎖
一般可以通過(guò)細(xì)化同步方法來(lái)實(shí)現(xiàn),只在真正需要保護(hù)共享資源的地方去拿鎖,并盡快釋放鎖,這樣可以有效降低在同步方法里調(diào)用其他同步方法的情況
2)順序索取鎖資源
如果實(shí)在無(wú)法避免嵌套索取鎖資源,則需要制定一個(gè)索取鎖資源的策略,先規(guī)劃好有哪些鎖,然后各個(gè)線程按照一個(gè)順序去索取,不要出現(xiàn)上面那個(gè)例子中不同順序,這樣就會(huì)有潛在的死鎖問(wèn)題
3)嘗試定時(shí)鎖
Java 5提供了更靈活的鎖工具,可以顯式地索取和釋放鎖。那么在索取鎖的時(shí)候可以設(shè)定一個(gè)超時(shí)時(shí)間,如果超過(guò)這個(gè)時(shí)間還沒(méi)索取到鎖,則不會(huì)繼續(xù)堵塞而是放棄此次任務(wù),示例代碼如下:
- public boolean trySendOnSharedLine(String message,
- long timeout, TimeUnit unit)
- throws InterruptedException {
- long nanosToLock = unit.toNanos(timeout)
- - estimatedNanosToSend(message);
- if (!lock.tryLock(nanosToLock, NANOSECONDS))
- return false;
- try {
- return sendOnSharedLine(message);
- } finally {
- lock.unlock();
- }
- }
這樣可以有效打破死鎖條件。
4)檢查死鎖
JVM采用thread dump的方式來(lái)識(shí)別死鎖的方式,可以通過(guò)操作系統(tǒng)的命令來(lái)向JVM發(fā)送thread dump的信號(hào),這樣可以查詢哪些線程死鎖。
過(guò)多串行化
用多線程實(shí)際上就是想并行地做事情,但這些事情由于某些依賴性必須串行工作,導(dǎo)致很多環(huán)節(jié)得串行化,這實(shí)際上很局限系統(tǒng)的可擴(kuò)展性,就算加CPU加線程,但性能卻沒(méi)有線性增長(zhǎng)。有個(gè)Amdahl定理可以說(shuō)明這個(gè)問(wèn)題:

其中,F(xiàn)是串行化比例,N是處理器數(shù)量,由上可知,只有盡可能減少串行化,才能最大化地提高可擴(kuò)展能力。降低串行化的關(guān)鍵就是降低鎖競(jìng)爭(zhēng),當(dāng)很多并行任務(wù)掛在鎖的獲取上,就是串行化的表現(xiàn)
過(guò)多鎖競(jìng)爭(zhēng)
過(guò)多鎖競(jìng)爭(zhēng)的危害是不言而喻的,那么看看有哪些辦法來(lái)降低鎖競(jìng)爭(zhēng)
1)縮小鎖的范圍
前面也談到這一點(diǎn),盡量縮小鎖保護(hù)的范圍,快進(jìn)快出,因此盡量不要直接在方法上使用synchronized關(guān)鍵字,而只是在真正需要線程安全保護(hù)的地方使用
2)減小鎖的粒度
Java 5提供了顯式鎖后,可以更為靈活的來(lái)保護(hù)共享變量。synchronized關(guān)鍵字(用在方法上)是默認(rèn)把整個(gè)對(duì)象作為鎖,實(shí)際上很多時(shí)候沒(méi)有必要用這么大一個(gè)鎖,這會(huì)導(dǎo)致這個(gè)類所有synchronized都得串行執(zhí)行??梢愿鶕?jù)真正需要保護(hù)的共享變量作為鎖,也可以使用更為精細(xì)的策略,目的就是要在真正需要串行的時(shí)候串行,舉一個(gè)例子:
- public class StripedMap {
- // Synchronization policy: buckets[n] guarded by locks[n%N_LOCKS]
- private static final int N_LOCKS = 16;
- private final Node[] buckets;
- private final Object[] locks;
- private static class Node { ... }
- public StripedMap(int numBuckets) {
- buckets = new Node[numBuckets];
- locks = new Object[N_LOCKS];
- for (int i = 0; i < N_LOCKS; i++)
- locks[i] = new Object();
- }
- private final int hash(Object key) {
- return Math.abs(key.hashCode() % buckets.length);
- }
- public Object get(Object key) {
- int hash = hash(key);
- synchronized (locks[hash % N_LOCKS]) {
- for (Node m = buckets[hash]; m != null; m = m.next)
- if (m.key.equals(key))
- return m.value;
- }
- return null;
- }
- public void clear() {
- for (int i = 0; i < buckets.length; i++) {
- synchronized (locks[i % N_LOCKS]) {
- buckets[i] = null;
- }
- }
- }
- ...
- }
上面這個(gè)例子是通過(guò)hash算法來(lái)把存取的值所對(duì)應(yīng)的hash值來(lái)作為鎖,這樣就只需要對(duì)hash值相同的對(duì)象存取串行化,而不是像HashTable那樣對(duì)任何對(duì)象任何操作都串行化。
3)減少共享資源的依賴
共享資源是競(jìng)爭(zhēng)鎖的源頭,在多線程開(kāi)發(fā)中盡量減少對(duì)共享資源的依賴,比如對(duì)象池的技術(shù)應(yīng)該慎重考慮,新的JVM對(duì)新建對(duì)象以做了足夠的優(yōu)化,性能非常好,如果用對(duì)象池不但不能提高多少性能,反而會(huì)因?yàn)殒i競(jìng)爭(zhēng)導(dǎo)致降低線程的可并發(fā)性。
4)使用讀寫(xiě)分離鎖來(lái)替換獨(dú)占鎖
Java 5提供了一個(gè)讀寫(xiě)分離鎖(ReadWriteLock)來(lái)實(shí)現(xiàn)讀-讀并發(fā),讀-寫(xiě)串行,寫(xiě)-寫(xiě)串行的特性。這種方式更進(jìn)一步提高了可并發(fā)性,因?yàn)橛行﹫?chǎng)景大部分是讀操作,因此沒(méi)必要串行工作。關(guān)于ReadWriteLock的具體使用可以參加一下示例:
- public class ReadWriteMap<K,V> {
- private final Map<K,V> map;
- private final ReadWriteLock lock = new ReentrantReadWriteLock();
- private final Lock r = lock.readLock();
- private final Lock w = lock.writeLock();
- public ReadWriteMap(Map<K,V> map) {
- this.map = map;
- }
- public V put(K key, V value) {
- w.lock();
- try {
- return map.put(key, value);
- } finally {
- w.unlock();
- }
- }
- // Do the same for remove(), putAll(), clear()
- public V get(Object key) {
- r.lock();
- try {
- return map.get(key);
- } finally {
- r.unlock();
- }
- }
- // Do the same for other read-only Map methods
- }
切換上下文
線程比較多的時(shí)候,操作系統(tǒng)切換線程上下文的性能消耗是不能忽略的,在構(gòu)建高性能web之路------web服務(wù)器長(zhǎng)連接 可以看出在進(jìn)程切換上的代價(jià),當(dāng)然線程會(huì)更輕量一些,不過(guò)道理是類似的
內(nèi)存同步
當(dāng)使用到synchronized、volatile或Lock的時(shí)候,都會(huì)為了保證可見(jiàn)性導(dǎo)致更多的內(nèi)存同步,這就無(wú)法享受到JMM結(jié)構(gòu)帶來(lái)了性能優(yōu)化。