| 好看請贊，養成習慣

• 你有一個思想，我有一個思想，我們交換后，一個人就有兩個思想

• If you can NOT explain it simply, you do NOT understand it well enough

現陸續將Demo代碼和技術文章整理在一起 Github實踐精選 ，方便大家閱讀查看，本文同樣收錄在此，覺得不錯，還請Star

看到本期內容這麼少，是不是心動了呢？

前言

上一篇萬字長文 Java AQS隊列同步器以及ReentrantLock的應用 為我們讀 JUC 源碼以及其設計思想做了足夠多的鋪墊，接下來的內容我將重點說明差異化，如果有些童鞋不是能很好的理解文中的一些內容，強烈建議回看上一篇文章，搞懂基礎內容，接下來的閱讀真會輕鬆加愉快

AQS 中我們介紹了獨佔式獲取同步狀態的多種情形：

• 獨佔式獲取鎖
• 可響應中斷的獨佔式獲取鎖
• 有超時限制的獨佔式獲取鎖

AQS 提供的模版方法裏面還差共享式獲取同步狀態沒有介紹，所以我們今天來揭開這個看似神秘的面紗

AQS 中的共享式獲取同步狀態

獨佔式是你中沒我，我中沒你的的一種互斥形式，共享式顯然就不是這樣了，所以他們的唯一區別就是：

同一時刻能否有多個線程同時獲取到同步狀態

簡單來說，就是這樣滴：

我們知道同步狀態 state 是維護在 AQS 中的，拋開可重入鎖的概念，我在上篇文章中也提到了，獨佔式和共享式控制同步狀態 state 的區別僅僅是這樣：

所以說想了解 AQS 的 xxxShared 的模版方法，只需要知道它是怎麼控制 state 的就好了

AQS共享式獲取同步狀態源碼分析

為了幫助大家更好的回憶內容，我將上一篇文章的兩個關鍵內容粘貼在此處，幫助大家快速回憶，關於共享式，大家只需要關注【騷紫色】就可以了

自定義同步器需要重寫的方法

AQS 提供的模版方法

故事就從這裏說起吧 (你會發現和獨佔式驚人的相似)，關鍵代碼都加了註釋

    public final void acquireShared(int arg) {
      	// 同樣調用自定義同步器需要重寫的方法，非阻塞式的嘗試獲取同步狀態，如果結果小於零，則獲取同步狀態失敗
        if (tryAcquireShared(arg) < 0)
          	// 調用 AQS 提供的模版方法，進入等待隊列
            doAcquireShared(arg);
    }

進入 doAcquireShared 方法：

    private void doAcquireShared(int arg) {
      	// 創建共享節點「SHARED」，加到等待隊列中
        final Node node = addWaiter(Node.SHARED);
        boolean failed = true;
        try {
            boolean interrupted = false;
          	// 進入“自旋”，這裏並不是純粹意義上的死循環，在獨佔式已經說明過
            for (;;) {
              	// 同樣嘗試獲取當前節點的前驅節點
                final Node p = node.predecessor();
              	// 如果前驅節點為頭節點，嘗試再次獲取同步狀態
                if (p == head) {
                  	// 在此以非阻塞式獲取同步狀態
                    int r = tryAcquireShared(arg);
                  	// 如果返回結果大於等於零，才能跳出外層循環返回
                    if (r >= 0) {
                      	// 這裡是和獨佔式的區別
                        setHeadAndPropagate(node, r);
                        p.next = null; // help GC
                        if (interrupted)
                            selfInterrupt();
                        failed = false;
                        return;
                    }
                }
                if (shouldParkAfterFailedAcquire(p, node) &&
                    parkAndCheckInterrupt())
                    interrupted = true;
            }
        } finally {
            if (failed)
                cancelAcquire(node);
        }
    }

上面代碼第 18 行我們提到和獨佔式獲取同步狀態的區別，貼心的給大家一個更直觀的對比：

差別只在這裏，所以我們就來看看 setHeadAndPropagate(node, r) 到底幹了什麼，我之前說過 JDK 源碼中的方法命名絕大多數還是非常直觀的，該方法直譯過來就是 【設置頭並且傳播/繁衍】。獨佔式只是設置了頭，共享式除了設置頭還多了一個傳播，你的疑問應該已經來了：

啥是傳播，為什麼會有傳播這個設置呢？

想了解這個問題，你需要先知道非阻塞共享式獲取同步狀態返回值的含義：

這裏說的傳播其實說的是 propagate > 0 的情況，道理也很簡單，當前線程獲取同步狀態成功了，還有剩餘的同步狀態可用於其他線程獲取，那就要通知在等待隊列的線程，讓他們嘗試獲取剩餘的同步狀態

如果要讓等待隊列中的線程獲取到通知，需要線程調用 release 方法實現的。接下來，我們走近 setHeadAndPropagate 一探究竟，驗證一下

  // 入參，node： 當前節點
	// 入參，propagate：獲取同步狀態的結果值，即上面方法中的變量 r
	private void setHeadAndPropagate(Node node, int propagate) {
    		// 記錄舊的頭部節點，用於下面的check
        Node h = head; 
    		// 將當前節點設置為頭節點
        setHead(node);
        
    		// 通過 propagate 的值和 waitStatus 的值來判斷是否可以調用 doReleaseShared 方法
        if (propagate > 0 || h == null || h.waitStatus < 0 ||
            (h = head) == null || h.waitStatus < 0) {
            Node s = node.next;
          	// 如果後繼節點為空或者後繼節點為共享類型，則進行喚醒後繼節點
    				// 這裏後繼節點為空意思是只剩下當前頭節點了，另外這裏的 s == null 也是判斷空指針的標準寫法
            if (s == null || s.isShared())
                doReleaseShared();
        }
    }

上面方法的大方向作用我們了解了，但是代碼中何時調用 doReleaseShared 的判斷邏輯還是挺讓人費解的，為什麼會有這麼一大堆的判斷，我們來逐個分析一下：

這裏的空判斷有點讓人頭大，我們先挑出來說明一下：

排除了其他判斷條件的干擾，接下來我們就專註分析 propagate 和 waitStatus 兩個判斷條件就可以了，這裏再將 waitStatus 的幾種狀態展示在這裏，幫助大家理解，【騷粉色】是我們一會要用到的：

propagate > 0

上面已經說過了，如果成立，直接短路後續判斷，然後根據 doReleaseShared 的判斷條件進行釋放

propagate > 0 不成立， h.waitStatus < 0 成立 （注意這裏的h是舊的頭節點）

什麼時候 h.waitStatus < 0 呢？拋開 CONDITION 的使用，只剩下 SIGNAL 和 PROPAGATE，想知道這個答案，需要提前看一下 doReleaseShared() 方法了：

    private void doReleaseShared() {
        for (;;) {
            Node h = head;
            if (h != null && h != tail) {
                int ws = h.waitStatus;
                if (ws == Node.SIGNAL) {
                  	// CAS 將頭節點的狀態設置為0                
                    if (!compareAndSetWaitStatus(h, Node.SIGNAL, 0))
                        continue;            // loop to recheck cases
                    // 設置成功后才能跳出循環喚醒頭節點的下一個節點
                  	unparkSuccessor(h);
                }
                else if (ws == 0 &&
                         // 將頭節點狀態CAS設置成 PROPAGATE 狀態
                         !compareAndSetWaitStatus(h, 0, Node.PROPAGATE))
                    continue;                // loop on failed CAS
            }
            if (h == head)                   // loop if head changed
                break;
        }
    }

從 doReleaseShared() 方法中可以看出：

• 如果讓 h.waitStatus < 0 成立，只能將其設置成 PROPAGATE = -3 的情況，設置成功的前提是 h 頭節點 expected 的狀態是 0；

• 如果 h.waitStatus = 0，是上述代碼第 8 行 CAS 設置成功，然後喚醒等待中的線程

所以猜測，當前線程執行到 h.waitStatus < 0 的判斷前，有另外一個線程剛好執行了 doReleaseShared() 方法，將 waitStatus 又設置成PROPAGATE = -3

這個理解有點繞，我們還是來畫個圖理解一下吧：

可能有同學還是不太能理解這麼寫的道理，我們一直說 propagate <> = 0 的情況，propagate = 0 代表的是當時/當時/當時 嘗試獲取同步狀態沒成功，但是之後可能又有共享狀態被釋放了，所以上面的邏輯是以防這種萬一，你懂的，嚴謹的併發就是要防止一切萬一，現在結合這個情景再來理解上面的判斷你是否豁然開朗了呢？

繼續向下看，

前序條件不成立，(h = head) == null || h.waitStatus < 0 注意這裏的h是新的頭節點）

有了上面鋪墊，這個就直接畫個圖就更好理解啦，其實就是沒有那麼巧有另外一個線程摻合了

相信到這裏你應該理解共享式獲取同步狀態的全部過程了吧，至於非阻塞共享式獲取同步狀態和帶有超時時間獲取同步狀態，結合本文講的 setHeadAndPropagate 邏輯和獨佔式獲取同步狀態的實現過程過程來看，真是一毛一樣，這裏就不再累述了，趕緊打開你的 IDE 去驗證一下吧

我們分析了AQS 的模版方法，還一直沒說 tryAcquireShared(arg) 這個方法是如何被重寫的，想要了解這個，我們就來看一看共享式獲取同步狀態的經典應用 Semaphore

Semaphore 的應用及源碼分析

Semaphore 概念

Semaphore 中文多翻譯為 【信號量】，我還特意查了一下劍橋辭典的英文解釋：

其實就是信號標誌（two flags），比如紅綠燈，每個交通燈產生兩種不同行為

• Flag1-紅燈：停車
• Flag2-綠燈：行車

在 Semaphore 裏面，什麼時候是紅燈，什麼時候是綠燈，其實就是靠 tryAcquireShared(arg) 的結果來表示的

• 獲取不到共享狀態，即為紅燈
• 獲取到共享狀態，即為綠燈

所以我們走近 Semaphore ，來看看它到底是怎麼應用 AQS 的，又是怎樣重寫 tryAcquireShared(arg) 方法的

Semaphore 源碼分析

先看一下類結構

看到這裏你是否有點跌眼鏡，和 ReentrantLock 相似的可怕吧，如果你有些陌生，再次強烈建議你回看上一篇文章 Java AQS隊列同步器以及ReentrantLock的應用 ，這裏直接提速對比看公平和非公平兩種重寫的 tryAcquireShared(arg) 方法，沒有意外，公平與否，就是判斷是否有前驅節點

方法內部只是計算 state 的剩餘值，那 state 的初始值是多少怎麼設置呢？當然也就是構造方法了：

		public Semaphore(int permits) {
      	// 默認仍是非公平的同步器，至於為什麼默認是非公平的，在上一篇文章中也特意說明過
        sync = new NonfairSync(permits);
    }
    
    NonfairSync(int permits) {
    		super(permits);
    }

super 方法，就會將初始值給到 AQS 中的 state

也許你發現了，當我們把 permits 設置為1 的時候，不就是 ReentrantLock 的互斥鎖了嘛，說的一點也沒錯，我們用 Semaphore 也能實現基本互斥鎖的效果

static int count;
//初始化信號量
static final Semaphore s 
    = new Semaphore(1);
//用信號量保證互斥    
static void addOne() {
  s.acquire();
  try {
    count+=1;
  } finally {
    s.release();
  }
}

But（英文聽力中的重點），Semaphore 肯定不是為這種特例存在的，它是共享式獲取同步狀態的一種實現。如果使用信號量，我們通常會將 permits 設置成大於1的值，不知道你是否還記得我曾在 為什麼要使用線程池? 一文中說到的池化概念，在同一時刻，允許多個線程使用連接池，每個連接被釋放之前，不允許其他線程使用。所以說 Semaphore 可以允許多個線程訪問一個臨界區，最終很好的做到一個限流/限流/限流 的作用

雖然 Semaphore 能很好的提供限流作用，說實話，Semaphore 的限流作用比較單一，我在實際工作中使用 Semaphore 並不是很多，如果真的要用高性能限流器，Guava RateLimiter 是一個非常不錯的選擇，我們後面會做分析，有興趣的可以提前了解一下

關於 Semaphore 源碼，就這麼三下五除二的結束了

總結

不知你有沒有感覺到，我們的節奏明顯加快了，好多原來分散的點在被瘋狂的串聯起來，如果按照這個方式來閱讀 JUC 源碼，相信你也不會一頭扎進去迷失方向，然後沮喪的退出 JUC 吧，然後面試背誦答案，然後忘記，然後再背誦？

跟上節奏，關於共享式獲取同步狀態，Semaphore 只不過是非常經典的應用，ReadWriteLock 和 CountDownLatch 日常應用還是非常廣泛的，我們接下來就陸續聊聊它們吧

靈魂追問

1. Semaphore 的 permits 設置成1 “等同於” 簡單的互斥鎖實現，那它和 ReentrantLock 的區別還是挺大的，都有哪些區別呢？
2. 你在項目中是如何使用 Semaphore 的呢？

參考

1. Java 併發實戰
2. Java 併發編程的藝術
3. https://blog.csdn.net/anlian523/article/details/106319294

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

目錄

• 併發問題的根源在哪
  • 緩存導致的可見性
  • 線程切換帶來的原子性
  • 編譯器優化帶來的有序性
• 主要解決辦法
  • 避免共享
  • Immutability（不變性）
  • 管程及其他工具

併發問題的根源在哪

首先，我們要知道併發要解決的是什麼問題？併發要解決的是單進程情況下硬件資源無法充分利用的問題。而造成這一問題的主要原因是CPU-內存-磁盤三者之間速度差異實在太大。如果將CPU的速度比作火箭的速度，那麼內存的速度就像火車，而最慘的磁盤，基本上就相當於人雙腿走路。

這樣造成的一個問題，就是CPU快速執行完它的任務的時候，很長時間都會在等待磁盤或是內存的讀寫。

計算機的發展有一部分就是如何重複利用資源，解決硬件資源之間效率的不平衡，而後就有了多進程，多線程的發展。並且演化出了各種為多進程（線程）服務的東西：

• CPU增加緩存機制，平衡與內存的速度差異
• 增加了多個概念，CPU時間片，程序計數器，線程切換等，用以更好得服務併發場景
• 編譯器的指令優化，希望在內部充分利用硬件資源

但是這樣一來，也會帶來新的併發問題，歸結起來主要有三個。

• 由於緩存導致的可見性問題
• 線程切換帶來的原子性問題
• 編譯器優化帶來的有序性問題

我們分別介紹這幾個：

緩存導致的可見性

CPU為了平衡與內存之間的性能差異，引入了CPU緩存，這樣CPU執行指令修改數據的時候就可以批量直接讀寫CPU緩存的內存，一個階段后再將數據寫回到內存。

但由於現在多核CPU技術的發展，各個線程可能運行在不同CPU核上面，每個CPU核各有各自的CPU緩存。前面說到對變量的修改通常都會先寫入CPU緩存，再寫回內存。這就會出現這樣一種情況，線程1修改了變量A，但此時修改后的變量A只存儲在CPU緩存中。這時候線程B去內存中讀取變量A，依舊只讀取到舊的值，這就是可見性問題。

線程切換帶來的原子性

為了更充分得利用CPU，引入了CPU時間片時間片的概念。進程或線程通過爭用CPU時間片，讓CPU可以更加充分得利用。

比如在進行讀寫磁盤等耗時高的任務時，就可以將寶貴的CPU資源讓出來讓其他線程去獲取CPU並執行任務。

但這樣的切換也會導致問題，那就是會破壞線程某些任務的原子性。比如java中簡單的一條語句count += 1。

映射到CPU指令有三條，讀取count變量指令，變量加1指令，變量寫回指令。雖然在高級語言（java）看來它就是一條指令，但實際上確是三條CPU指令，並且這三條指令的原子性無法保證。也就是說，可能在執行到任意一條指令的時候被打斷，CPU被其他線程搶佔了。而這個期間變量值可能會被修改，這裏就會引發數據不一致的情況了。所以高併發場景下，很多時候都會通過鎖實現原子性。而這個問題也是很多併發問題的源頭。

編譯器優化帶來的有序性

因為現在程序員編寫的都是高級語言，編譯器需要將用戶的代碼轉成CPU可以執行的指令。

同時，由於計算機領域的不斷髮展，編譯器也越來越智能，它會自動對程序員編寫的代碼進行優化，而優化中就有可能出現實際執行代碼順序和編寫的代碼順序不一樣的情況。

而這種破壞程序有序性的行為，在有些時候會出現一些非常微妙且難以察覺的併發編程bug。

舉個簡單的例子，我們常見的單例模式是這樣的：

public class Singleton {
 
 private Singleton() {}

 private static Singleton sInstance;

 public static Singleton getInstance() {

    if (sInstance == null) {	//第一次驗證是否為null
      synchronized (Singleton.class) {   //加鎖
        if (sInstance == null) {	  //第二次驗證是否為null
          sInstance = new Singleton();  //創建對象
                 }
             }
         }
    return sInstance;
    }

}

即通過兩段判斷加鎖來保證單例的成功生成，但在極小的概率下，可能會出現異常情況。原因就出現在sInstance = new Singleton();這一行代碼上。這行代碼，我們理解的執行順序應該是這樣：

1. 為Singleton象分配一個內存空間。
2. 在分配的內存空間實例化對象。
3. 把Instance 引用地址指向內存空間。

但在實際編譯的過程中，編譯器有可能會幫我們進行優化，優化完它的順序可能變成如下：

1. 為Singleton對象分配一個內存空間。
2. 把instance 引用地址指向內存空間。
3. 在分配的內存空間實例化對象。

按照優化完的順序，當併發訪問的時候，可能會出現這樣的情況

1. A線程進入方法進行第1次instance == null判斷。
2. 此時A線程發現instance 為null 所以對Singleton.class加鎖。
3. 然後A線程進入方法進行第2次instance == null判斷。
4. 然後A線程發現instance 為null，開始進行對象實例化。
5. 為對象分配一個內存空間。
   6.把Instance 引用地址指向內存空間（而就在這個指令完成后，線程B進入了方法）。
6. B線程首先進入方法進行第1次instance == null判斷。
7. B線程此時發現instance 不為null ，所以它會直接返回instance (而此時返回的instance 是A線程還沒有初始化完成的對象)

最終線程B拿到的instance 是一個沒有實例化對象的空內存地址，所以導致instance使用的過程中造成程序錯誤。解決辦法很簡單，可以給sInstance對象加上一個關鍵字，volatile，這樣編譯器就不會亂優化，有關volatile的具體內容後續再細說。

主要解決辦法

通過上面的介紹，其實可以歸納無論是CPU緩存，線程切換還是編譯器優化亂序，出現問題的核心都是因為多個線程要併發讀寫某個變量或併發執行某段代碼。那麼我們可以控制，一次只讓一個線程執行變量讀寫就可以了，這就是互斥。

而在某些時候，互斥還不夠，還需要一定的條件。比如一個生產者一個消費者併發，生產者向隊列存東西，消費者向隊列拿東西。那麼生產者寫的時候要保證存的時候隊列不是滿的，消費者要保證拿的時候隊列非空。這種線程與線程間需要通信協作的情況，稱為同步，同步可以說是更複雜的互斥。

既然知道了併發編程的根源以及同步和互斥，那我們來看看有哪些解決的思路。其實一共也就三種：

• 避免共享
• Immutability（不變性）
• 管程及其他工具

下面我們分別說說這三種方案的優缺點

避免共享

我們先來說說避免共享，其實避免共享說是線程本地存儲技術，在java中指的一般就是Threadlocal。ThreadLocal會為每個線程提供一個本地副本，每個線程都只會修改自己的ThreadLocal變量。這樣一來就不會出現共享變量，也就不會出現衝突了。

其實現原理是在ThreadLocal內部維護一個ThreadLocalMap，每次有線程要獲取對應變量的時候，先獲取當前線程，然後根據不同線程取不同的值，典型的以空間換時間。

所以ThreadLocal還是比較適用於需要共享資源，且資源佔用空間不大的情況。比如一些連接的session啊等等。但是這種模式應用場景也較為有限，比如需要同步情況就難以勝任。

Immutability（不變性）

Immutability在函數式中用得比較多，函數式編程的一個主要目的是要寫出無副作用的代碼，有關什麼是無副作用可以參考我以前的文章Scala函數式編程指南（一） 函數式思想介紹。而無副作用的一個主要特點就是變量都是Immutability即不可變的，即創建對象后不會再修改對象，比如scala默認的變量和數據結構都是不可變的。而在java中，不變性變量即通過final修飾的變量，如String，Long，Double等類型都是Immutability的，它們的內部實現都是基於final關鍵字的。

那這又和併發編程有什麼關係呢？其實啊，併發問題很大部分原因就是因為線程切換破壞了原子性，這又導致線程隨意對變量的讀寫破壞了數據的一致性。而不變性就不必擔心這個問題，因為變量都是不變，不可寫只能讀的。在這種編程模式下，你要修改一個變量，那麼只能新生成一個。這樣做的好處很明顯，但壞處也是顯而易見，那就是引入了額外的編程複雜度，喪失了代碼的可讀性和易用性。

因為如此，不變性的併發解決方案其實相對而已沒那麼廣泛，其中比較有代表性的算是Actor併發編程模型，我以前也有討論過，有興趣可以看看Actor模型淺析 一致性和隔離性，這種編程模型和常規併發解決方案有很顯著的差異。按我的了解，Acctor模式多用在分佈式系統的一些協調功能，比如維持集群中多個機器的心跳通信等等。如果在單機併發環境下，還是下面要介紹的管程類工具才是利器。

管程及其他工具

其實最早的操作系統中，解決併發問題用的是信號量，信號量通過兩個原子操作wait(S)，和signal(S)（俗稱P，V操作）來實現訪問資源互斥和同步。比如下面這個小例子：

//整型信號量定義
int S;

//P操作
wait(S){
  while(S<=0);
  S--;
}

//V操作
signal(S){
  S++;
}

雖然信號量方便有效，但信號量要對每個共享資源都實現對應的P和V操作，這使得併發編程中可能要出現大量的P，V操作，並且這部分內容難以抽象出來。

為了更好地實現同步互斥，於是就產生了管程（即Monitor，也有翻譯為監視器），值得一提的是，管程也有幾種模型，分別是：Hasen模型，Hoare模型和MESA模型。其中MESA模型應用最廣泛，java也是參考自MESA模型。這裏簡單介紹下管程的理論知識，這部分內容參考自進程同步機制—–為進程併發執行保駕護航，希望了解更多管程理論知識的童鞋可以看看。

我們來通過一個經典的生產-消費隊列來解釋，如下圖

我們先解釋下圖中右半部分的內容，右上角有一個等待調用的線程隊列，管程中每次只能有一個線程在執行任務，所以多個任務需要等待。然後是各個名詞的意思，生產-消費需要往隊列寫入和取出東西，這裏的隊列就是共享變量，對共享資源進行操作稱之為過程（入隊和出隊兩個過程）。而向隊列寫入和取出是有條件的，寫入的時候隊列必須是非滿的，取出的時候隊列必須是非空的，這兩個條件被稱為條件變量。

然後再來看看左半部分的內容，假設線程T1讀取共享變量（即隊列），此時發現隊列為空（條件變量之一），那麼T1此時需要等待，去哪裡等呢？去條件變量隊列不能為空對應的隊列中去等待。此時另一個線程T2向共享變量隊列寫數據，通過了條件變量隊列不能滿，那麼寫完后就會通知線程T1。但因為管程的限制，管程中只能有一個線程在執行，所以T1線程不能立即執行，它會回到右上角的線程等待隊列等待（不同的管程模型在這裡是有分歧的，比如Hasen模型是立即中斷T2線程讓隊列中下一個線程執行）。

解釋完這個圖，管程的概念也就呼之欲出了，

hansen對管程的定義如下：一個管程定義了一個數據結構和能力為併發進程所執行（在該數據結構上）的一組操作，這組操作能同步進程和改變管程中的數據。

本質上，管程是對共享資源以及對共享資源的操作抽象成變量和方法，要操作共享變量僅能通過管程提供的方法（比如上面的入隊和出隊）間接訪問。所以你會發現管程其實和面向對象的理念是十分相近的，在java中，主要提供了低層次了synchronized關鍵字和wait()，notify()等方法。同時還提供了高層次的ReenTrantLock和Condition來實現管程模型。

以上~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化

一：背景

1. 講故事

自從這個純內存項目進了大客戶之後，搞得我現在對內存和CPU特別敏感，跑一點數據內存幾個G的上下，特別沒有安全感，總想用windbg抓幾個dump看看到底是哪一塊導致的，是我的代碼還是同事的代碼？ 很多看過我博客的老朋友總是留言讓我出一套windbg的系列或者視頻，我也不會呀，沒辦法，人在江湖飄，遲早得挨上幾刀，逼着也得會幾個花架子，廢話不多說，這一篇就來看看 HashSet 是如何擴容的。

二：HashSet的擴容機制

1. 如何查看

了解如何擴容，最好的辦法就是翻看HashSet底層源碼，最粗暴的入口點就是 HashSet.Add 方法。

從圖中可以看到最後的初始化是用 Initialize 的，而且裏面有這麼一句神奇的代碼: int prime = HashHelpers.GetPrime(capacity);，從字面意思看是獲取一個質數，哈哈，有點意思，什麼叫質數？ 簡單說就是只能被 1 和 自身 整除的數就叫做質數，那好奇心就來了，一起看看質數是怎麼算的吧！ 再次截圖。

從圖中看，HashSet底層為了加速默認定義好了 72 個質數，最大的一個質數是 719w，換句話就是說當元素個數大於 719w 的時候，就只能使用 IsPrime 方法動態計算質數，如下代碼：

public static bool IsPrime(int candidate)
{
	if ((candidate & 1) != 0)
	{
		int num = (int)Math.Sqrt(candidate);
		for (int i = 3; i <= num; i += 2)
		{
			if (candidate % i == 0)
			{
				return false;
			}
		}
		return true;
	}
	return candidate == 2;
}

看完了整個流程，我想你應該明白了，當你第一次Add的時候，默認的空間佔用是 72 個預定義中最小的一個質數 3，看過我之前文章的朋友知道List的默認大小是4，後面就是簡單粗暴的 * 2 處理，如下代碼。

private void EnsureCapacity(int min)
{
	if (_items.Length < min)
	{
		int num = (_items.Length == 0) ? 4 : (_items.Length * 2);
	}
}

2. HashSet 二次擴容探究

當HashSet的個數達到3之後，很顯然要進行二次擴容，這一點不像List用一個 EnsureCapacity 方法搞定就可以了，然後細看一下怎麼擴容。

public static int ExpandPrime(int oldSize)
{
	int num = 2 * oldSize;
	if ((uint)num > 2146435069u && 2146435069 > oldSize)
	{
		return 2146435069;
	}
	return GetPrime(num);
}

從圖中可以看到，最後的擴容是在 ExpandPrime 方法中完成的，流程就是先 * 2， 再取最接近上限的一個質數，也就是 7 ，然後將 7 作為 HashSet 新的Size，如果你非要看演示，我就寫一小段代碼證明一下吧，如下圖：

2. 您嗅出風險了嗎？

<1> 時間上的風險

為了方便演示，我把 72 個預定義的最後幾個質數显示出來。

public static readonly int[] primes = new int[72]
{
	2009191,
	2411033,
	2893249,
	3471899,
	4166287,
	4999559,
	5999471,
	7199369
};

也就是說，當HashSet的元素個數為 2893249 的時候觸發擴容變成了 2893249 * 2 => 5786498 最接近的一個質數為：5999471，也就是 289w 暴增到了 599w，一下子就是 599w -289w = 310w 的空間虛占，這可是增加了兩倍多哦，嚇人不？ 下面寫個代碼驗證下。

        static void Main(string[] args)
        {
            var hashSet = new HashSet<int>(Enumerable.Range(0, 2893249));

            hashSet.Add(int.MaxValue);

            Console.Read();
        }

0:000> !clrstack -l

000000B8F4DBE500 00007ffaf00132ae ConsoleApplication3.Program.Main(System.String[]) [C:\4\ConsoleApp1\ConsoleApp1\Program.cs @ 16]
    LOCALS:
        0x000000B8F4DBE538 = 0x0000020e0b8fcc08
0:000> !DumpObj /d 0000020e0b8fcc08
Name:        System.Collections.Generic.HashSet`1[[System.Int32, System.Private.CoreLib]]
Size:        64(0x40) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0-preview.5.20278.1\System.Collections.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ffaf0096d10  4000017        8       System.Int32[]  0 instance 0000020e2025e9f8 _buckets
00007ffaf00f7ad0  4000018       10 ...ivate.CoreLib]][]  0 instance 0000020e2bea1020 _slots
00007ffaeffdf828  4000019       28         System.Int32  1 instance          2893250 _count
0:000> !DumpObj /d 0000020e2025e9f8
Name:        System.Int32[]
Size:        23997908(0x16e2dd4) bytes
Array:       Rank 1, Number of elements 5999471, Type Int32 (Print Array)
Fields:
None

而且最重要的是，這裡是一次性擴容的，而非像redis中實現的那樣漸進式擴容，時間開銷也是大家值得注意的。

<2> 空間上的風險

這個有什麼風險呢？可以看一下：289w 和 599w 兩個HashSet的佔用空間大小，這也是我最敏感的。

        static void Main(string[] args)
        {
            var hashSet1 = new HashSet<int>(Enumerable.Range(0, 2893249));

            var hashSet2 = new HashSet<int>(Enumerable.Range(0, 2893249));
            hashSet2.Add(int.MaxValue);

            Console.Read();
        }

0:000> !clrstack -l
OS Thread Id: 0x4a44 (0)
000000B1B4FEE460 00007ffaf00032ea ConsoleApplication3.Program.Main(System.String[]) [C:\4\ConsoleApp1\ConsoleApp1\Program.cs @ 18]
    LOCALS:
        0x000000B1B4FEE4B8 = 0x000001d13363cc08
        0x000000B1B4FEE4B0 = 0x000001d13363d648

0:000> !objsize 0x000001d13363cc08
sizeof(000001D13363CC08) = 46292104 (0x2c25c88) bytes (System.Collections.Generic.HashSet`1[[System.Int32, System.Private.CoreLib]])
0:000> !objsize 0x000001d13363d648
sizeof(000001D13363D648) = 95991656 (0x5b8b768) bytes (System.Collections.Generic.HashSet`1[[System.Int32, System.Private.CoreLib]])

可以看到， hashSet1的佔用： 46292104 / 1024 / 1024 = 44.1M， hashSet2 的佔用 : 95991656 / 1024 / 1024 = 91.5M,一下子就浪費了： 91.5 - 44.1 = 47.4M。

如果你真以為僅僅浪費了 47.4M 的話，那你就大錯特錯了，不要忘了底層在擴容的時候，使用新的 size 覆蓋了老的 size，而這個 老的 size 集合在GC還沒有回收的時候會一直佔用堆上空間的，這個能聽得懂嗎？ 如下圖：

要驗證的話可以用 windbg 去託管堆上抓一下 Slot[] m_slots 和 int[] m_buckets 兩個數組，我把代碼修改如下：

    static void Main(string[] args)
    {
        var hashSet2 = new HashSet<int>(Enumerable.Range(0, 2893249));
        hashSet2.Add(int.MaxValue);
        Console.Read();
    }


0:011> !dumpheap -stat
00007ffaf84f7ad0        3    123455868 System.Collections.Generic.HashSet`1+Slot[[System.Int32, System.Private.CoreLib]][]

這裏就拿 Slot[] 說事，從上面代碼可以看到，託管堆上有三個 Slot[] 數組，這就有意思了，怎麼有三個哈，是不是有點懵逼，沒關係，我們將三個 Slot[] 的地址找出來，一個一個看。

0:011> !DumpHeap /d -mt 00007ffaf84f7ad0
         Address               MT     Size
0000016c91308048 00007ffaf84f7ad0 16743180     
0000016c928524b0 00007ffaf84f7ad0 34719012     
0000016ce9e61020 00007ffaf84f7ad0 71993676  

0:011> !gcroot 0000016c91308048
Found 0 unique roots (run '!gcroot -all' to see all roots).
0:011> !gcroot 0000016c928524b0
Found 0 unique roots (run '!gcroot -all' to see all roots).
0:011> !gcroot 0000016ce9e61020
Thread 2b0c:
    0000006AFAB7E5F0 00007FFAF84132AE ConsoleApplication3.Program.Main(System.String[]) [C:\4\ConsoleApp1\ConsoleApp1\Program.cs @ 15]
        rbp-18: 0000006afab7e618
            ->  0000016C8000CC08 System.Collections.Generic.HashSet`1[[System.Int32, System.Private.CoreLib]]
            ->  0000016CE9E61020 System.Collections.Generic.HashSet`1+Slot[[System.Int32, System.Private.CoreLib]][]

從上面可以看到，我通過 gcroot 去找這三個地址的引用根，有兩個是沒有的，最後一個有的自然就是新的 599w 的size，對不對，接下來用 !do 打出這三個地址的值。

0:011> !do 0000016c91308048
Name:        System.Collections.Generic.HashSet`1+Slot[[System.Int32, System.Private.CoreLib]][]
Size:        16743180(0xff7b0c) bytes
Array:       Rank 1, Number of elements 1395263, Type VALUETYPE (Print Array)
Fields:
None

0:011> !do 0000016c928524b0
Name:        System.Collections.Generic.HashSet`1+Slot[[System.Int32, System.Private.CoreLib]][]
Size:        34719012(0x211c524) bytes
Array:       Rank 1, Number of elements 2893249, Type VALUETYPE (Print Array)
Fields:
None

0:011> !do 0000016ce9e61020
Name:        System.Collections.Generic.HashSet`1+Slot[[System.Int32, System.Private.CoreLib]][]
Size:        71993676(0x44a894c) bytes
Array:       Rank 1, Number of elements 5999471, Type VALUETYPE (Print Array)
Fields:
None

從上面的 Rank 1, Number of elements 信息中可以看到，原來託管堆不僅有擴容前的Size ：2893249，還有更前一次的擴容Size: 1395263，所以按這種情況算： 託管堆上的總大小近似為： 23.7M + 47.4M + 91.5M = 162.6M，我去，不簡單把。。。 也就是說：託管堆上有 162.6 - 91.5 =71.1M 的未回收垃圾 剛才的 47.4M 的空間虛佔用，總浪費為:118.5M，但願我沒有算錯。。。

3. 有解決方案嗎？

在List中大家可以通過 Capacity 去控制List的Size，但是很遺憾，在 HashSet 中並沒有類似的解決方案，只有一個很笨拙的裁剪方法: TrimExcess，用於將當前Size擴展到最接近的 質數 值， 如下代碼所示：

public void TrimExcess()
{
	int prime = HashHelpers.GetPrime(m_count);
	Slot[] array = new Slot[prime];
	int[] array2 = new int[prime];
	int num = 0;
	for (int i = 0; i < m_lastIndex; i++)
	{
		if (m_slots[i].hashCode >= 0)
		{
			array[num] = m_slots[i];
			int num2 = array[num].hashCode % prime;
			array[num].next = array2[num2] - 1;
			array2[num2] = num + 1;
			num++;
		}
	}
}

應用到本案例就是將 289w 限制到 347w，仍然有 58w的空間佔用。 如下圖：

三： 總結

HashSet的時間和空間上虛占遠比你想象的大很多，而且實占也不小，因為底層用到了雙數組 m_slots 和 m_buckets，每個Slot還有三個元素: struct Slot { int hashCode;internal int next;internal T value; }，所以了解完原理之後謹慎着用吧。

如您有更多問題與我互動，掃描下方進來吧~

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

※教你寫出一流的銷售文案?

※超省錢租車方案

系列文章

1. 基於 abp vNext 和 .NET Core 開發博客項目 – 使用 abp cli 搭建項目
2. 基於 abp vNext 和 .NET Core 開發博客項目 – 給項目瘦身，讓它跑起來
3. 基於 abp vNext 和 .NET Core 開發博客項目 – 完善與美化，Swagger登場
4. 基於 abp vNext 和 .NET Core 開發博客項目 – 數據訪問和代碼優先
5. 基於 abp vNext 和 .NET Core 開發博客項目 – 自定義倉儲之增刪改查
6. 基於 abp vNext 和 .NET Core 開發博客項目 – 統一規範API，包裝返回模型
7. 基於 abp vNext 和 .NET Core 開發博客項目 – 再說Swagger，分組、描述、小綠鎖
8. 基於 abp vNext 和 .NET Core 開發博客項目 – 接入GitHub，用JWT保護你的API
9. 基於 abp vNext 和 .NET Core 開發博客項目 – 異常處理和日誌記錄
10. 基於 abp vNext 和 .NET Core 開發博客項目 – 使用Redis緩存數據
11. 基於 abp vNext 和 .NET Core 開發博客項目 – 集成Hangfire實現定時任務處理
12. 基於 abp vNext 和 .NET Core 開發博客項目 – 用AutoMapper搞定對象映射
13. 基於 abp vNext 和 .NET Core 開發博客項目 – 定時任務最佳實戰（一）
14. 基於 abp vNext 和 .NET Core 開發博客項目 – 定時任務最佳實戰（二）
15. 基於 abp vNext 和 .NET Core 開發博客項目 – 定時任務最佳實戰（三）
16. 基於 abp vNext 和 .NET Core 開發博客項目 – 博客接口實戰篇（一）
17. 基於 abp vNext 和 .NET Core 開發博客項目 – 博客接口實戰篇（二）
18. 基於 abp vNext 和 .NET Core 開發博客項目 – 博客接口實戰篇（三）
19. 基於 abp vNext 和 .NET Core 開發博客項目 – 博客接口實戰篇（四）
20. 基於 abp vNext 和 .NET Core 開發博客項目 – 博客接口實戰篇（五）
21. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（一）
22. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（二）
23. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（三）
24. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（四）
25. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（五）
26. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（六）
27. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（七）
28. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（八）
29. 基於 abp vNext 和 .NET Core 開發博客項目 – Blazor 實戰系列（九）
30. 基於 abp vNext 和 .NET Core 開發博客項目 – 終結篇之發布項目

上一篇完成了標籤模塊和友情鏈接模塊的所有功能，本篇來繼續完成博客最後的模塊，文章的管理。

文章列表 & 刪除

先將分頁查詢的列表給整出來，這塊和首頁的分頁列表是類似的，就是多了個Id字段。

先添加兩條路由規則。

@page "/admin/posts"
@page "/admin/posts/{page:int}"

新建返回數據默認QueryPostForAdminDto.cs。

//QueryPostForAdminDto.cs
using System.Collections.Generic;

namespace Meowv.Blog.BlazorApp.Response.Blog
{
    public class QueryPostForAdminDto
    {
        /// <summary>
        /// 年份
        /// </summary>
        public int Year { get; set; }

        /// <summary>
        /// Posts
        /// </summary>
        public IEnumerable<PostBriefForAdminDto> Posts { get; set; }
    }
}

//PostBriefForAdminDto.cs
namespace Meowv.Blog.BlazorApp.Response.Blog
{
    public class PostBriefForAdminDto : PostBriefDto
    {
        /// <summary>
        /// 主鍵
        /// </summary>
        public int Id { get; set; }
    }
}

然後添加所需的參數：當前頁碼、限制條數、總頁碼、文章列表返回數據模型。

/// <summary>
/// 當前頁碼
/// </summary>
[Parameter]
public int? page { get; set; }

/// <summary>
/// 限制條數
/// </summary>
private int Limit = 15;

/// <summary>
/// 總頁碼
/// </summary>
private int TotalPage;

/// <summary>
/// 文章列表數據
/// </summary>
private ServiceResult<PagedList<QueryPostForAdminDto>> posts;

然後在初始化函數OnInitializedAsync()中調用API獲取文章數據.

/// <summary>
/// 初始化
/// </summary>
protected override async Task OnInitializedAsync()
{
    var token = await Common.GetStorageAsync("token");
    Http.DefaultRequestHeaders.Add("Authorization", $"Bearer {token}");

    // 設置默認值
    page = page.HasValue ? page : 1;

    await RenderPage(page);
}

/// <summary>
/// 點擊頁碼重新渲染數據
/// </summary>
/// <param name="page"></param>
/// <returns></returns>
private async Task RenderPage(int? page)
{
    // 獲取數據
    posts = await Http.GetFromJsonAsync<ServiceResult<PagedList<QueryPostForAdminDto>>>($"/blog/admin/posts?page={page}&limit={Limit}");

    // 計算總頁碼
    TotalPage = (int)Math.Ceiling((posts.Result.Total / (double)Limit));
}

在初始化中判斷page參數，如果沒有值給他設置一個默認值1。RenderPage(int? page)方法是調用API返回數據，並計算出總頁碼值。

最後在頁面上進行數據綁定。

<AdminLayout>
    @if (posts == null)
    {
        <Loading />
    }
    else
    {
        <div class="post-wrap archive">
            <NavLink style="float:right" href="/admin/post"><h3>~~~ 新增文章 ~~~</h3></NavLink>
            @if (posts.Success && posts.Result.Item.Any())
            {
                @foreach (var item in posts.Result.Item)
                {
                    <h3>@item.Year</h3>
                    @foreach (var post in item.Posts)
                    {
                        <article class="archive-item">
                            <NavLink title="刪除" @onclick="@(async () => await DeleteAsync(post.Id))"></NavLink>
                            <NavLink title="編輯" @onclick="@(async () => await Common.NavigateTo($"/admin/post/{post.Id}"))"></NavLink>
                            <NavLink target="_blank" class="archive-item-link" href="@("/post" + post.Url)">@post.Title</NavLink>
                            <span class="archive-item-date">@post.CreationTime</span>
                        </article>
                    }
                }
                <nav class="pagination">
                    @for (int i = 1; i <= TotalPage; i++)
                    {
                        var _page = i;

                        if (page == _page)
                        {
                            <span class="page-number current">@_page</span>
                        }
                        else
                        {
                            <a class="page-number" @onclick="@(() => RenderPage(_page))" href="/admin/posts/@_page">@_page</a>
                        }
                    }
                </nav>
            }
            else
            {
                <ErrorTip />
            }
        </div>
    }
</AdminLayout>

HTML內容放在組件AdminLayout中，當 posts 沒加載完數據的時候显示加載組件<Loading />。

在頁面上循環遍歷文章數據和翻頁頁碼，每篇文章標題前面添加兩個按鈕刪除和編輯，同時單獨加了一個新增文章的按鈕。

刪除文章調用DeleteAsync(int id)方法，需要傳遞參數，當前文章的id。

新增和編輯按鈕都跳轉到”/admin/post”頁面，當編輯的時候將id也傳過去即可，路由規則為：”/admin/post/{id}”。

刪除文章“方法如下：

/// <summary>
/// 刪除文章
/// </summary>
/// <param name="id"></param>
/// <returns></returns>
private async Task DeleteAsync(int id)
{
    // 彈窗確認
    bool confirmed = await Common.InvokeAsync<bool>("confirm", "\n真的要幹掉這篇該死的文章嗎");

    if (confirmed)
    {
        var response = await Http.DeleteAsync($"/blog/post?id={id}");

        var result = await response.Content.ReadFromJsonAsync<ServiceResult>();

        if (result.Success)
        {
            await RenderPage(page);
        }
    }
}

刪除之前進行二次確認，避免誤刪，當確認刪除之後調用刪除文章API，最後重新渲染數據即可。

新增 & 更新文章

完成了後台文章列表的查詢和刪除，現在整個博客模塊功能就差新增和更新文章了，勝利就在前方，沖啊。

這塊的開發工作耗費了我太多時間，因為想使用 markdown 來寫文章，找了一圈下來沒有一個合適的組件，所以退而求次只能選擇現有的markdown編輯器來實現了。

我這裏選擇了開源的編輯器Editor.md，有需要的可以去 Github 自己下載，https://github.com/pandao/editor.md 。

將下載的資源包解壓放在 wwwroot 文件夾下，默認是比較大的，而且還有很多示例文件，我已經將其精簡了一番，可以去我 Github 下載使用。

先來看下最終的成品效果吧。

是不是感覺還可以，廢話不多說，接下里告訴大家如何實現。

在 Admin 文件夾下添加post.razor組件，設置路由，並且引用一個樣式文件，在頁面中引用樣式文件好像不太符合標準，不過無所謂了，這個後台就自己用，而且還就這一個頁面用得到。

@page "/admin/post"
@page "/admin/post/{id:int}"

<link href="./editor.md/css/editormd.css" rel="stylesheet" />

<AdminLayout>
    ...
</AdminLayout>

把具體HTML內容放在組件AdminLayout中。

因為新增和編輯放在同一個頁面上，所以當id參數不為空的時候需要添加一個id參數，同時默認一進來就讓頁面显示加載中的組件，當頁面和數據加載完成后在显示具體的內容，所以在指定一個布爾類型的是否加載參數isLoading。

我們的編輯器主要依賴JavaScript實現的，所以這裏不可避免要使用到JavaScript了。

在app.js中添加幾個全局函數。

switchEditorTheme: function () {
    editor.setTheme(localStorage.editorTheme || 'default');
    editor.setEditorTheme(localStorage.editorTheme === 'dark' ? 'pastel-on-dark' : 'default');
    editor.setPreviewTheme(localStorage.editorTheme || 'default');
},
renderEditor: async function () {
	await this._loadScript('./editor.md/lib/zepto.min.js').then(function () {
	    func._loadScript('./editor.md/editormd.js').then(function () {
	        editor = editormd("editor", {
	            width: "100%",
	            height: 700,
	            path: './editor.md/lib/',
	            codeFold: true,
	            saveHTMLToTextarea: true,
	            emoji: true,
	            atLink: false,
	            emailLink: false,
	            theme: localStorage.editorTheme || 'default',
	            editorTheme: localStorage.editorTheme === 'dark' ? 'pastel-on-dark' : 'default',
	            previewTheme: localStorage.editorTheme || 'default',
	            toolbarIcons: function () {
	                return ["bold", "del", "italic", "quote", "ucwords", "uppercase", "lowercase", "h1", "h2", "h3", "h4", "h5", "h6", "list-ul", "list-ol", "hr", "link", "image", "code", "preformatted-text", "code-block", "table", "datetime", "html-entities", "emoji", "watch", "preview", "fullscreen", "clear", "||", "save"]
	            },
	            toolbarIconsClass: {
	                save: "fa-check"
	            },
	            toolbarHandlers: {
	                save: function () {
	                    func._shoowBox();
	                }
	            },
	            onload: function () {
	                this.addKeyMap({
	                    "Ctrl-S": function () {
	                        func._shoowBox();
	                    }
	                });
	            }
	        });
	    });
	});
},
_shoowBox: function () {
    DotNet.invokeMethodAsync('Meowv.Blog.BlazorApp', 'showbox');
},
_loadScript: async function (url) {
    let response = await fetch(url);
    var js = await response.text();
    eval(js);
}

renderEditor主要實現了動態加載JavaScript代碼，將markdown編輯器渲染出來。這裏不多說，都是Editor.md示例裏面的代碼。

為了兼容暗黑色主題，這裏還加了一個切換編輯器主題的JavaScript方法，switchEditorTheme。

_shoowBox就厲害了，這個方法是調用的.NET組件中的方法，前面我們用過了在Blazor中調用JavaScript，這裏演示了JavaScript中調用Blazor中的組件方法。

現在將所需的幾個參數都添加到代碼中。

/// <summary>
/// 定義一個委託方法，用於組件實例方法調用
/// </summary>
private static Func<Task> action;

/// <summary>
/// 默認隱藏Box
/// </summary>
private bool Open { get; set; } = false;

/// <summary>
/// 修改時的文章Id
/// </summary>
[Parameter]
public int? Id { get; set; }

/// <summary>
/// 格式化的標籤
/// </summary>
private string tags { get; set; }

/// <summary>
/// 默認显示加載中
/// </summary>
private bool isLoading = true;

/// <summary>
/// 文章新增或者修改輸入參數
/// </summary>
private PostForAdminDto input;

/// <summary>
/// API返回的分類列表數據
/// </summary>
private ServiceResult<IEnumerable<QueryCategoryForAdminDto>> categories;

大家看看註釋就知道參數是做什麼的了。

現在我們在初始化函數中將所需的數據通過API獲取到。

/// <summary>
/// 初始化
/// </summary>
/// <returns></returns>
protected override async Task OnInitializedAsync()
{
    action = ChangeOpenStatus;

    var token = await Common.GetStorageAsync("token");
    Http.DefaultRequestHeaders.Add("Authorization", $"Bearer {token}");

    if (Id.HasValue)
    {
        var post = await Http.GetFromJsonAsync<ServiceResult<PostForAdminDto>>($"/blog/admin/post?id={Id}");

        if (post.Success)
        {
            var _post = post.Result;
            input = new PostForAdminDto
            {
                Title = _post.Title,
                Author = _post.Author,
                Url = _post.Url,
                Html = _post.Html,
                Markdown = _post.Markdown,
                CategoryId = _post.CategoryId,
                Tags = _post.Tags,
                CreationTime = _post.CreationTime
            };

            tags = string.Join(",", input.Tags);
        }
    }
    else
    {
        input = new PostForAdminDto()
        {
            Author = "阿星Plus",
            CreationTime = DateTime.Now
        };
    }

    categories = await Http.GetFromJsonAsync<ServiceResult<IEnumerable<QueryCategoryForAdminDto>>>("/blog/admin/categories");

    // 渲染編輯器
    await Common.InvokeAsync("window.func.renderEditor");

    // 關閉加載
    isLoading = !isLoading;
}

action是一個異步的委託，在初始化中執行了ChangeOpenStatus方法，這個方法等會說，然後獲取localStorage中token的值。

通過參數Id是否有值來判斷當前是新增文章還是更新文章，如果有值就是更新文章，這時候需要根據id去將文章的數據拿到賦值給PostForAdminDto對象展示在頁面上，如果沒有可以添加幾個默認值給PostForAdminDto對象。

因為文章需要分類和標籤的數據，同時這裏將分類的數據也查出來，標籤默認是List列表，將其轉換成字符串類型。

但完成上面操作后，調用JavaScript方法renderEditor渲染渲染編輯器，最後關閉加載，显示頁面。

現在來看看頁面。

<AdminLayout>
    @if (isLoading)
    {
        <Loading />
    }
    else
    {
        <div class="post-box">
            <div class="post-box-item">
                <input type="text" placeholder="標題" autocomplete="off" @bind="@input.Title" @bind:event="oninput" @onclick="@(() => { Open = false; })" />
                <input type="text" placeholder="作者" autocomplete="off" @bind="@input.Author" @bind:event="oninput" @onclick="@(() => { Open = false; })" />
            </div>
            <div class="post-box-item">
                <input type="text" placeholder="URL" autocomplete="off" @bind="@input.Url" @bind:event="oninput" @onclick="@(() => { Open = false; })" />
                <input type="text" placeholder="時間" autocomplete="off" @bind="@input.CreationTime" @bind:format="yyyy-MM-dd HH:mm:sss" @bind:event="oninput" @onclick="@(() => { Open = false; })" />
            </div>
            <div id="editor">
                <textarea style="display:none;">@input.Markdown</textarea>
            </div>

            <Box OnClickCallback="@SubmitAsync" Open="@Open" ButtonText="發布">
                <div class="box-item">
                    <b>分類：</b>
                    @if (categories.Success && categories.Result.Any())
                    {
                        @foreach (var item in categories.Result)
                        {
                            <label><input type="radio" name="category" value="@item.Id" @onchange="@(() => { input.CategoryId = item.Id; })" checked="@(item.Id == input.CategoryId)" />@item.CategoryName</label>
                        }
                    }
                </div>
                <div class="box-item"></div>
                <div class="box-item">
                    <b>標籤：</b>
                    <input type="text" @bind="@tags" @bind:event="oninput" />
                </div>
            </Box>
        </div>
    }
</AdminLayout>

添加了四個input框，分別用來綁定標題、作者、URL、時間，<div id="editor"></div>中為編輯器所需。

然後我這裏還是把之前的彈窗組件搞出來了，執行邏輯不介紹了，在彈窗組件中自定義显示分類和標籤的內容，將獲取到的分類和標籤綁定到具體位置。

每個分類都是一個radio標籤，並且對應一個點擊事件，點哪個就把當前分類的Id賦值給PostForAdminDto對象。

所有的input框都使用@bind和@bind:event綁定數據和獲取數據。

Box彈窗組件這裏自定義了按鈕文字，ButtonText="發布"。

/// <summary>
/// 改變Open狀態，通知組件渲染
/// </summary>
private async Task ChangeOpenStatus()
{
    Open = true;

    var markdown = await Common.InvokeAsync<string>("editor.getMarkdown");
    var html = await Common.InvokeAsync<string>("editor.getHTML");

    if (string.IsNullOrEmpty(input.Title) || string.IsNullOrEmpty(input.Url) ||
        string.IsNullOrEmpty(input.Author) || string.IsNullOrEmpty(markdown) ||
        string.IsNullOrEmpty(html))
    {
        await Alert();
    }

    input.Html = html;
    input.Markdown = markdown;

    StateHasChanged();
}

/// <summary>
/// 暴漏給JS執行，彈窗確認框
/// </summary>
[JSInvokable("showbox")]
public static void ShowBox()
{
    action.Invoke();
}

/// <summary>
/// alert提示
/// </summary>
/// <returns></returns>
private async Task Alert()
{
    Open = false;

    await Common.InvokeAsync("alert", "\n好像漏了點什麼吧");
    return;
}

現在可以來看看ChangeOpenStatus方法了，這個是改變當前彈窗狀態的一個方法。為什麼需要這個方法呢?

因為在Blazor中JavaScript想要調用組件內的方法，方法必須是靜態的，那麼只能通過這種方式去實現了，在靜態方法是不能夠直接改變彈窗的狀態值的。

其實也可以不用這麼麻煩，因為我在編輯器上自定義了一個按鈕，為了好看一些所以只能曲折一點，嫌麻煩的可以直接在頁面上搞個按鈕執行保存數據邏輯也是一樣的。

使用JSInvokableAttribute需要在_Imports.razor中添加命名空間@using Microsoft.JSInterop。

ChangeOpenStatus中獲取到文章內容：HTML和markdown，賦值給PostForAdminDto對象，要先進行判斷頁面上的幾個參數是否有值，沒值的話給出提示執行Alert()方法，最後使用StateHasChanged()通知組件其狀態已更改。

Alert方法就是調用原生的JavaScriptalert方法，給出一個提示。

ShowBox就是暴漏給JavaScript的方法，使用DotNet.invokeMethodAsync('Meowv.Blog.BlazorApp', 'showbox');進行調用。

那麼現在一切都正常進行的情況下，點擊編輯器上自定義的保存按鈕，頁面上值不為空的情況下就會彈出我們的彈窗組件Box。

最後在彈窗組件的回調方法中執行新增文章還是更新文章。

/// <summary>
/// 確認按鈕點擊事件
/// </summary>
/// <returns></returns>
private async Task SubmitAsync()
{
    if (string.IsNullOrEmpty(tags) || input.CategoryId == 0)
    {
        await Alert();
    }

    input.Tags = tags.Split(",");

    var responseMessage = new HttpResponseMessage();

    if (Id.HasValue)
        responseMessage = await Http.PutAsJsonAsync($"/blog/post?id={Id}", input);
    else
        responseMessage = await Http.PostAsJsonAsync("/blog/post", input);

    var result = await responseMessage.Content.ReadFromJsonAsync<ServiceResult>();
    if (result.Success)
    {
        await Common.NavigateTo("/admin/posts");
    }
}

打開彈窗后執行回調事件之前還是要判斷值是否為空，為空的情況下還是給出alert提示，此時將tags標籤還是轉換成List列表，根據Id是否有值去執行新增數據或者更新數據，最終成功后跳轉到文章列表頁。

本片到這裏就結束了，主要攻克了在Blazor中使用Markdown編輯器實現新增和更新文章，這個系列差不多就快結束了，預計還有2篇的樣子，感謝各位的支持。

開源地址：https://github.com/Meowv/Blog/tree/blog_tutorial

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

※別再煩惱如何寫文案,掌握八大原則!

※網頁設計最專業,超強功能平台可客製化