大家使用多線程無非是為了提高性能，但如果多線程使用不當(dāng)，不但性能提升不明顯，而且會(huì)使得資源消耗更大。下面列舉一下可能會(huì)造成多線程性能問題的點(diǎn)：
- 死鎖
- 過多串行化
- 過多鎖競(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)其他鎖
一般可以通過細(xì)化同步方法來實(shí)現(xiàn)，只在真正需要保護(hù)共享資源的地方去拿鎖，并盡快釋放鎖，這樣可以有效降低在同步方法里調(diào)用其他同步方法的情況
2）順序索取鎖資源
如果實(shí)在無法避免嵌套索取鎖資源，則需要制定一個(gè)索取鎖資源的策略，先規(guī)劃好有哪些鎖，然后各個(gè)線程按照一個(gè)順序去索取，不要出現(xiàn)上面那個(gè)例子中不同順序，這樣就會(huì)有潛在的死鎖問題
3）嘗試定時(shí)鎖
Java 5提供了更靈活的鎖工具，可以顯式地索取和釋放鎖。那么在索取鎖的時(shí)候可以設(shè)定一個(gè)超時(shí)時(shí)間，如果超過這個(gè)時(shí)間還沒索取到鎖，則不會(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的方式來識(shí)別死鎖的方式，可以通過操作系統(tǒng)的命令來向JVM發(fā)送thread dump的信號(hào)，這樣可以查詢哪些線程死鎖。
過多串行化
用多線程實(shí)際上就是想并行地做事情，但這些事情由于某些依賴性必須串行工作，導(dǎo)致很多環(huán)節(jié)得串行化，這實(shí)際上很局限系統(tǒng)的可擴(kuò)展性，就算加CPU加線程，但性能卻沒有線性增長。有個(gè)Amdahl定理可以說明這個(gè)問題：
其中，F(xiàn)是串行化比例，N是處理器數(shù)量，由上可知，只有盡可能減少串行化，才能最大化地提高可擴(kuò)展能力。降低串行化的關(guān)鍵就是降低鎖競(jìng)爭(zhēng)，當(dāng)很多并行任務(wù)掛在鎖的獲取上，就是串行化的表現(xiàn)
過多鎖競(jìng)爭(zhēng)
過多鎖競(jìng)爭(zhēng)的危害是不言而喻的，那么看看有哪些辦法來降低鎖競(jìng)爭(zhēng)
1）縮小鎖的范圍
前面也談到這一點(diǎn)，盡量縮小鎖保護(hù)的范圍，快進(jìn)快出，因此盡量不要直接在方法上使用synchronized關(guān)鍵字，而只是在真正需要線程安全保護(hù)的地方使用
2）減小鎖的粒度
Java 5提供了顯式鎖后，可以更為靈活的來保護(hù)共享變量。synchronized關(guān)鍵字（用在方法上）是默認(rèn)把整個(gè)對(duì)象作為鎖，實(shí)際上很多時(shí)候沒有必要用這么大一個(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è)例子是通過hash算法來把存取的值所對(duì)應(yīng)的hash值來作為鎖，這樣就只需要對(duì)hash值相同的對(duì)象存取串行化，而不是像HashTable那樣對(duì)任何對(duì)象任何操作都串行化。
3）減少共享資源的依賴
共享資源是競(jìng)爭(zhēng)鎖的源頭，在多線程開發(fā)中盡量減少對(duì)共享資源的依賴，比如對(duì)象池的技術(shù)應(yīng)該慎重考慮，新的JVM對(duì)新建對(duì)象以做了足夠的優(yōu)化，性能非常好，如果用對(duì)象池不但不能提高多少性能，反而會(huì)因?yàn)殒i競(jìng)爭(zhēng)導(dǎo)致降低線程的可并發(fā)性。
4）使用讀寫分離鎖來替換獨(dú)占鎖
Java 5提供了一個(gè)讀寫分離鎖（ReadWriteLock）來實(shí)現(xiàn)讀-讀并發(fā)，讀-寫串行，寫-寫串行的特性。這種方式更進(jìn)一步提高了可并發(fā)性，因?yàn)橛行﹫?chǎng)景大部分是讀操作，因此沒必要串行工作。關(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ù)器長連接 可以看出在進(jìn)程切換上的代價(jià)，當(dāng)然線程會(huì)更輕量一些，不過道理是類似的
內(nèi)存同步
當(dāng)使用到synchronized、volatile或Lock的時(shí)候，都會(huì)為了保證可見性導(dǎo)致更多的內(nèi)存同步，這就無法享受到JMM結(jié)構(gòu)帶來了性能優(yōu)化。