如何理解Netty的鎖

如何理解Netty的鎖，相信很多沒有經(jīng)驗(yàn)的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個(gè)問題。

樺甸網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)于2013年創(chuàng)立到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

1、分析同步問題的核心三要素

• 原子性：“并無一氣呵成，豈能無懈可擊”，如：高并發(fā)下的 i++

• 可見性：“你做的改變，別人看不見”

• 有序性：“不按套路出牌”

2、鎖的分類

• 競爭的態(tài)度：樂觀鎖(java.util.concurrent 包中的原子類) 與 悲觀鎖(synchronized)

• 等待鎖的人是否公平：公平鎖 new ReentrantLock(true) 與 非公平鎖 new ReentrantLock()

• 是否可共享：共享鎖 與 獨(dú)享鎖 - ReadWriteLock，其讀鎖是共享鎖，其寫鎖是獨(dú)享鎖

3、Netty 玩轉(zhuǎn)鎖的五個(gè)關(guān)鍵點(diǎn)

3.1、在意鎖的對象和范圍 -> 減少粒度

例：初始化 channel (io.netty.bootstrap.ServerBootstrap#init)

Synchronized method -> Synchronized block

void init(Channel channel) throws Exception {
        Map<ChannelOption<?>, Object> options = this.options0();
        synchronized(options) {
            setChannelOptions(channel, options, logger);
        }

        Map<AttributeKey<?>, Object> attrs = this.attrs0();
        synchronized(attrs) {
            Iterator var5 = attrs.entrySet().iterator();

            while(true) {
                if (!var5.hasNext()) {
                    break;
                }

                Entry<AttributeKey<?>, Object> e = (Entry)var5.next();
                AttributeKey<Object> key = (AttributeKey)e.getKey();
                channel.attr(key).set(e.getValue());
            }
        }
        //...
    }

3.2、注意鎖的對象本身大小 -> 減少空間占用

例：統(tǒng)計(jì)待發(fā)送的字節(jié)數(shù) (io.netty.channel.ChannelOutboundBuffer)

AtomicLong -> Volatile long + AtomicLongFieldUpdater

AtomicLong vs long

前者是一個(gè)對象，包含對象頭(object header)以用來保存 hashcode、lock等信息，32 位系統(tǒng)占用 8 字節(jié)，64 位系統(tǒng)占用 16 字節(jié)，所以在 64 位系統(tǒng)下：

• volatile long = 8 bytes

• AtomicLong = 8 bytes (volatile long) + 16 bytes (object header) + 8 bytes (引用) = 32 bytes

至少節(jié)約 24 字節(jié)！

結(jié)論：
Atomic* objects -> Volatile primary type + static Atomic*FieldUpdater

原子類型的對象可以用 volatile 修飾的基礎(chǔ)類型來代替，以節(jié)省空間

3.3、注意鎖的速度 -> 提高速度（提高并發(fā)性）

例1：記錄內(nèi)存分配字節(jié)數(shù)等功能用到的 LongCounter (io.netty.util.internal.PlatformDependent#newLongCounter())

高并發(fā)時(shí)：java.util.concurrent.atomic.AtomicLong -> java.util.concurrent.atomic.LongAdder (JDK)

結(jié)論：及時(shí)衡量，使用jdk最新功能

例2：曾經(jīng)根據(jù)不同情況，選擇不同的并發(fā)包實(shí)現(xiàn)：JDK < 1.8 考慮 ConcurrentHashMapV8(ConcurrentHashMap 在 JDK8 中的版本)

3.4、不同場景選擇不同的并發(fā)類 -> 因需而變

例1：關(guān)閉和等待關(guān)閉事件執(zhí)行器(Event Executor):

Object.wait/notify -> CountDownLatch

io.netty.util.concurrent.SingleThreadEventExecutor#threadLock

例2：Nio Event Loop 中負(fù)責(zé)存儲 task 的 Queue

Jdk's LinkedBlockingQueue(MPMC) -> jctools' MPSC

MPMC: muti-producer & muti-consumer
MPSC: muti-producer & simple-consumer

io.netty.util.internal.PlatformDependent.Mpsc#newMpscQueue(int)

3.5、衡量好鎖的價(jià)值 -> 能不用就不用

生活場景：

飯店提供了很多包廂，服務(wù)模式：

• 一個(gè)服務(wù)員固定服務(wù)某幾個(gè)包廂模式；

• 所有服務(wù)員服務(wù)所有的包廂模式；

表面上看，前者效率沒有后者高，但實(shí)際上它避免了服務(wù)員間的溝通（上下文切換）等開銷，避免客人與服務(wù)員之間導(dǎo)出亂串，管理簡單。

局部串行：Channel 的 I/O 請求處理 Pipeline 是串行的

整體并行：多個(gè)串行化線程(Nio Event Loop)

Netty 應(yīng)用場景下：局部串行 + 整體并行 > 一個(gè)隊(duì)列 + 多個(gè)線程模式：

• 降低用戶開發(fā)難度、邏輯簡單、提升處理性能

• 避免鎖帶來的上下文切換和并發(fā)保護(hù)等額外開銷

看完上述內(nèi)容，你們掌握如何理解Netty的鎖的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝各位的閱讀！

當(dāng)前名稱：如何理解Netty的鎖
文章鏈接：http://bm7419.com/article26/psogcg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供搜索引擎優(yōu)化、網(wǎng)站設(shè)計(jì)公司、品牌網(wǎng)站制作、品牌網(wǎng)站建設(shè)、電子商務(wù)、做網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)