大家好,我是哪吒。
上一章提到了一個(gè)關(guān)于 i++ 和 ++i 的面試題打趴了所有人,最終方案是在兩個(gè)方法上添加synchronized關(guān)鍵字,從而避免i++的線程安全問題,不過,這樣真的好嗎?在所有有線程安全的方法都添加synchronized?
答案是顯而易見的,不行。
synchronized會(huì)極大的降低程序的性能,導(dǎo)致整個(gè)程序幾乎只能支持單線程操作,性能顯著降低。
那么,如何解決呢?
鎖的粒度更小了,也解決了這個(gè)問題,確實(shí)可以的。
package com.guor.thread;public class SynchronizedTest2 { int a = 1; int b = 1; public void add() { System.out.println("add start"); synchronized (this) { for (int i = 0; i < 10000; i++) { a++; b++; } } System.out.println("add end"); } public synchronized void compare() { System.out.println("compare start"); synchronized (this) { for (int i = 0; i < 10000; i++) { boolean flag = a < b; if (flag) { System.out.println("a=" + a + ",b=" + b + "flag=" + flag + ",a < b = " + (a < b)); } } } System.out.println("compare end"); } public static void main(String[] args) { SynchronizedTest2 synchronizedTest = new SynchronizedTest2(); new Thread(() -> synchronizedTest.add()).start(); new Thread(() -> synchronizedTest.compare()).start(); }}
為了更好的優(yōu)化,有的時(shí)候可以將synchronized代碼塊變?yōu)閰^(qū)分讀寫場(chǎng)景的讀寫鎖,也可以考慮悲觀鎖和樂觀鎖的區(qū)分。
對(duì)于讀寫場(chǎng)景比較多的情況,可以使用ReentrantReadWriteLock區(qū)分讀寫,再次降低鎖的粒度,提高程序的性能。
ReentrantReadWriteLock 還可以選擇提供了公平鎖,在沒有明確必須使用公平鎖的情況下,盡量不要使用公平鎖,公平鎖會(huì)使程序性能降低很多很多。
簡(jiǎn)單來說,公平鎖(誰(shuí)先排隊(duì),誰(shuí)先執(zhí)行),非公平鎖(不用排隊(duì),每個(gè)人都有機(jī)會(huì))。
有一天早上,云韻、美杜莎、小醫(yī)仙結(jié)伴去買醬香拿鐵,到了咖啡店,先排隊(duì),一個(gè)一個(gè)來。不一會(huì),哪吒來了,也買醬香拿鐵,只能在末尾排隊(duì)。這個(gè)就是公平鎖。
本文鏈接:http://www.www897cc.com/showinfo-26-12358-0.html簡(jiǎn)單聊一聊公平鎖和非公平鎖,Parallel并行流
聲明:本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。郵件:2376512515@qq.com