北京日報消息，北京城市管理委員會表示，已正式發文要求加強電動汽車充電基礎設施建設和管理，其中，新建停車場必須預留配建充電設施條件，全市機關單位內部停車場應含充電停車位，新建社區停車位須100%具有安裝充電樁條件。

資料顯示，截至今年7月底，北京市新能源汽車數量達14.14萬輛，全市已累計建成約9.75萬個充電樁，基本形成六環內平均服務半徑5公里的公用充電網，其中，個人自用樁約6.87萬個，配建比約75%，商場商圈、交通樞紐等公共停車區域建成1,895處、約1.75萬個。

北京市城管委相關負責人表示，大力新建公用充電樁是破解新能源車推廣困難的重要工作之一，日前市政府已發佈《關於進一步加強電動汽車充電基礎設施建設和管理的實施意見》，首次對新建、既有建築的停車位配建充電設施作出了量化要求。

新規定將充電設施配建指標納入規劃設計規範，明確新建建築配建停車場及公共停車場中充電設施的建設比例或預留建設安裝條件。其中，辦公類建築不低於配建停車位的25%，商業類及公共停車場庫(含P+R停車場)不低於20%，居住類按照配建停車位的100%規劃建設，其他類公建如醫院、學校、文體設施等不低於15%規劃建設。

另外，新建社區100%規劃建設，係指每個停車位都要具備安裝條件，讓車主買車後就能直接裝充電樁，不用再申請改電增容。

同時，對於具備電源條件的既有辦公區、大型商場等公用停車場，新規要求必須配建不低於車位數量10%的公用充電樁。對於老舊社區住戶而言，購買電動車最難的關卡就是無法安裝充電樁，而此次頒佈的新規將充電設施建設納入北京市老舊社區綜合改造範圍內，引導物業公司、業主委員會積極支持和配合充電設施建設。

此次新規也提出，北京全市各級機關、企事業單位內部停車場都要配建公用充電設施。按規定，北京市各級公共機構(包括各級政府機關、事業單位、社會組織)和國有企業新建內部停車場，充電樁數量應不低於車位數的25%，或預留建設安裝條件。

（本文內容由授權使用。圖片出處：public domain CC0）

本站聲明:網站內容來源於EnergyTrend https://www.energytrend.com.tw/ev/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

 一.嘮嘮WebAssembly的發展歷程

　　目前有很多支持WebAssembly的項目，但發展最快的是Blazor，這是一個構建單頁面的.NET技術，目前已經從Preview版本升級到了beta版本，微軟計劃在2020年5月發布Blazor的第一個版本。

　　Blazor是什麼？它是一項將C＃和.NET都放入瀏覽器的Microsoft技術。它使用WebAssembly來工作，WebAssembly是一種高性能的管道，可以將代碼預編譯為緊湊的二進制格式。最重要的是，每個主流瀏覽器（包括移動版本）都支持WebAssembly。

　　十年前，JavaScript統治世界還不是很明顯。Flash和Silverlight也正在運行。這二個都需要使用瀏覽器插件來完成工作，並且都以不同的用戶界面方法替換了HTML。這種方法使他們在功能方面遙遙領先於JavaScript，但隨着移動互聯網的出現，他們就慢慢過時。

　　但隨後從最初的Javascript再到微軟的JScript和CEnvi的ScriptEase三足鼎立，再到最後的統一標準，當時微軟憑藉Windows系統捆綁Internet Explorer的先天優勢擊潰Netscape后，兩大巨頭就此進入了長達數年的靜默期，JavaScript就是在這樣的情況下被構想出來的，當時的瀏覽器之王，Netscape Navigator創始人Marc Andreessen認為Netscape需要一種“glue language”來支持HTML，讓Web設計師和兼職程序員可以很容易地使用它來組裝諸如圖像和插件之類的組件，且代碼是可以直接寫在網頁標記中。除此之外微軟的步步緊逼也迫使Andreessen不得不聘請Brendan Eich，及早將Scheme編程語言嵌入到Netscape Navigator中。1995年，JavaScript以Mocha為名開發，並於9月在Netscape Navigator 2.0的測試版中首次發布，當時被稱為LiveScript，12月，在Netscape Navigator 2.0 beta 3中部署時被重命名為JavaScript 。雖然Netscape Navigator在Chrome、Internet Explorer和Firefox等多款瀏覽器的圍追堵截中最終落敗，但是JavaScript卻推動了網頁的發展，並一直被沿用至今。

　　這是一個諷刺。在JavaScript征服世界的同時，播下了一顆很小的種子，這可能會在將來的某個時候暗示JavaScript的終結。那顆種子是名為asm.js的實驗技術。

　　這是Mozilla的開發人員在2013年完成的一個古怪的實驗。他們正在尋找在瀏覽器中運行高性能代碼的方法。但是與插件不同，asm.js並未嘗試在瀏覽器旁邊運行。相反，它的目的是直接通過Javascript的虛擬化。

　　從本質上講，asm.js是簡潔，優化的JavaScript語法。它比普通的JavaScript運行得更快，因為它避免了該語言的慢動態部分。但是認識到它的網絡瀏覽器也可以應用其他優化，從而大大提高性能。換句話說，asm.js遵循黃金法則- 不要破壞網絡 -同時提供通往未來改進的途徑。Firefox團隊使用asm.js以及名為的轉碼工具來獲取用C ++構建的實時3D遊戲，並將其放入Web瀏覽器中，並且僅在JavaScript和原始野心上運行。

　　有人問為什麼asm.js好在哪裡，簡單而言，它的性能比JavaScript高几百倍，當然是在沒有谷歌的V8引擎之下，因為JavaScript是弱類型語言，它需要猜測你的數據類型來進行編譯，這樣的情況下，在我看來它肯定需要遍歷完一個方法，然後再進行運算，與其這樣我為什麼不打個標識呢？當然在不破壞JavaScript的情況下，arm.js選擇了一個騷氣的想法，如果你想你的數據類型是int，那麼聲明一個值就變成了變量名|0，就這樣它的目的就達到了。

　　儘管asm.js實驗產生了一些令人眼花撩亂的演示，但工作的開發人員基本上忽略了它。對他們來說，這隻是超越現代的一個有趣方面。但這隨着WebAssembly的創建而改變。

　　WebAssembly既是asm.js的後繼產品，又是一項截然不同的技術。這是一種緊湊的二進制代碼格式。像asm.js一樣，WebAssembly代碼也被輸入到JavaScript執行環境中。它具有相同的沙箱和相同的運行時環境。與asm.js一樣，WebAssembly的編譯方式也可以提高效率。但是現在，這些效率比有以前更加明顯，並且瀏覽器可以完全跳過JavaScript解析階段。對於普通的邏輯，WebAssembly遠比常規JavaScript快，幾乎與本機編譯的代碼一樣快。

 　　WebAssembly於2015年首次出現。如今，桌面和移動設備上的四大瀏覽器（Chrome，Edge，Safari和Firefox）已完全支持它。儘管可以通過將WebAssembly代碼轉換為asm.js來實現向後兼容，但Internet Explorer不支持它。就讓IE涼透吧！但需要注意的是WebAssembly無法迴避JavaScript，因為它已鎖定在JavaScript運行時環境中。實際上，WebAssembly需要與至少一些普通的JavaScript代碼一起運行，因為它不能直接訪問頁面。這意味着如果不通過JavaScript層，就無法操縱DOM或接收事件。

 　　聽我說起來，這是一個限制，但聰明的微軟開發者已經找到了走私的方法，在瀏覽器中下載一個微型.NET運行時，作為已編譯的WASM文件。此運行時處理JavaScript互操作，並提供基本服務，它能給我們提供GC或者其它用法。Blazor不是唯一一個由WebAssembly支持的實驗。考慮一下，它旨在將Python放入瀏覽器中，並帶有用於數據分析的高級數學工具包。據我所知這應該使用emscripten的編譯器。

 　　人們常說，何時Javascript能夠替代服務器端語言，又有人說什麼時候可以代替桌面級應用程序，所以WebAssembly並不是用來代替JavaScript的。而是為了解決現代問題，如果它做到了，那就真的做到了！所以作為一個程序員，你應該對WebAssembly引起足夠的重視，未來快速加載Web應用程序的需求肯定會增加。

 　　就現在我們的.NET Core提供了兩種Blazor模板，包括Blazor Server 以及 Blazor WebAssembly。

• Blazor Server使用熟悉的.NET環境在Web服務器上運行代碼。訣竅是瀏覽器和服務器之間的通信方式。當用戶與頁面進行交互時，JavaScript代碼將回調到發生實際頁面生命周期的服務器。（要建立此連接，該頁面使用名為的Microsoft API ）運行服務器端代碼后，Blazor Server呈現該頁面並將更改發送回Web頁面，該Web頁面將相應地進行更新。
• Blazor WebAssembly使用由WebAssembly提供支持的微型.NET運行時在瀏覽器中運行代碼。您的客戶端代碼可以訪問許多熟悉的.NET庫，並且您使用C＃語言編寫它，您仍然可以像在JavaScript頁面中一樣在Web服務器上調用API。
  

　　Blazor Server是一種具有一些有趣用例的技術，但是由於不斷的通信，您顯然會犧牲一些性能-甚至不用問脫機功能。Blazor WebAssembly是受到最多宣傳的一種，也是我們在本文中探討的一種。

　　關於Blazor，程序員最常見的誤解是將其C＃代碼編譯為WebAssembly，然後發送到瀏覽器，然後執行。這種方法並非不可能-Blazor的創建者暗示他們將來可能會嘗試這種技術。但是如今Blazor的工作方式並不是如此。

　　換句話說，如今的Blazor是當您訪問使用Blazor的網頁時，該頁面將從下載按比例縮小的.NET運行時開始。然後它將下載您的應用程序以及您的應用程序使用的任何其他.NET庫，所有這些都在其本機IL中。最後，Blazor運行時執行IL。

二.配置您的開發環境

 　　由於Blazor是一個預發布的早期Beta產品。基礎結構的關鍵部分正在發生變化，您將無法獲得與其他類型的Microsoft項目相同級別的工具支持。我嘗試在Visual Studio 2019中進行編碼，需要注意的是您需要勾選.NET FrameWork 4.8 以及 .NET Core 3.0 + ，這樣您才具有Web Assembly的項目。完成設置后，您可以輕鬆創建Blazor項目。只需啟動Visual Studio，創建一個新項目，然後選擇“ Blazor App”項目即可。Visual Studio會詢問您是否需要Blazor Server應用程序或Blazor WebAssembly應用程序.

 三.Blazor的數據綁定與組件傳值

　　由於關於Blazor的一篇我編寫的文章，未能提及更深入的內容，那麼現在我將要介紹一下高級的Blazor用法，到最後還會有一個糖果，園友力作的Blazor UI！多麼激動人心的時刻，那麼趕快開始吧.

3.1 Child Component

　　在Blazor的Child Component中可以使用[Parameter] 關鍵字，來進行傳值的定義，我們可以這麼來做，現在只是提一下這個概念，下面會仔細說下組件之間如何進行跨組件綁定值。

<div>
    <p>標題：@title</p>
</div>
@code{
    [Parameter]
    public string title { get; set; }
}

隨後在調用時，Visual Studio IDE 就可以直接向您的視覺進行提示輸入相關屬性。

<Demorazor title="Hello 博客園的兄弟們！"></Demorazor>

運行效果如下：

3.2 single Bind and Two-way binding

single bind就不用說了，新建項目自帶的模板Counter示例那就是如此。

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="IncrementCount">Click me</button>

@code {
    private int currentCount = 0;

    private void IncrementCount()
    {
        currentCount++;
    }
}

此處 @currentCount 值根據點擊按鈕的數量遞增Click me。<p>標記元素中的值會自動刷新，無需任何組件刷新。

two-way binding 我們可以自定義我們的事件 一共分為二中綁定方式 包括@bind 和 @Bind-Value，值得一提的是還可以通過使用event參數指定@bind-value屬性, 使用其他事件來綁定屬性或字段。例如第四個文本框就是綁定changeString採用oninput事件的屬性，以到達在文本框的值更改時激發，經過我的測試如果你的綁定事件是Javascript中不存在的，那麼也無妨，不會報出系統級別的異常，我想如果是從IL轉換到WebAssembly中，就會直接過濾掉，但是Visual Studio 2019 沒有給我們提示，也讓我們編譯通過，即使是當前的最高16.0.4 預覽版也是如此，這個是令我詫異的。

<p>
    <span>在這裏可以使用bind-value 或者 bind 當然這裏確保您不使用其它事件！</span>
    <input @bind-value="changeString" />
    <p>這是我輸入的內容: @changeString</p>
</p>
<p>
    <span>oninput</span>
    <input @bind-value="changeString" @bind-value:event="oninput" />
</p>

@code {
    string changeString = "";
}  

運行效果如下：

 3.3 Component bindings

 　　想要跨組件進行綁定屬性值，可以使用,@bind-{property}可在其中跨組件綁定屬性值，我們試着嘗試，首先我們創建一個子控件，這個blazor就叫Baby，有一個身份證Id的屬性和出生地址。

　　 EventCallback的用法非常廣泛，它可以跨組件共享方法和屬性，如不寫下面的兩個屬性，則就會報錯。

@page "/baby"
<h2>Child Compoent</h2>
<p>出生的Baby IdentityCard:@Baby_IdentityCrad_Id</p>
<h3>在{@Baby_new_Address} 生的</h3>
@code {
    [Parameter]
    public string Baby_IdentityCrad_Id{ get; set; }

    /// <summary>
    /// 這個屬性也是牛的雅皮~~~ hhh
    /// </summary>
    [Parameter]
    public string Baby_new_Address{ get; set; }
    
    [Parameter]
    public EventCallback<string> Baby_IdentityCrad_IdChanged { get; set; }

    [Parameter]
    public EventCallback<string> Baby_new_AddressChanged { get; set; }
}

 　　有什麼樣的兒子就會有什麼樣的爸爸？ 現在我們創建出父親，那就直接叫做一個Father.razor吧~

@page "/father"
<h3>Father</h3>

<Baby @bind-Baby_IdentityCrad_Id="@id_Card"
      @bind-Baby_new_Address="@address">
</Baby>
<button class="btn btn-primary" @onclick="@ChangeTheYear">new baby()</button>
@code {
    public string id_Card { get; set; }
    public string address { get; set; }
    private void ChangeTheYear()
    {
        id_Card = Guid.NewGuid().ToString();
        address = "老張";
    }
}

運行效果如下：

 

 如果要在子組件中定義事件，則可以MouseEventArgs來接受設備上的事件，然後再進行附加事件。

[Parameter]
public EventCallback<MouseEventArgs> OnClick { get; set; }

四.級聯傳值

 　　在某些情況下, 使用組件參數將數據從祖先組件流式傳輸到附屬組件是不方便的, 尤其是在有多個組件層時。 級聯值和參數通過提供一種方便的方法, 使上級組件為其所有子代組件提供值。 級聯值和參數還提供了一種方法來協調組件。我們試着去構建一個例子，首先創建一個最頂層的組件。

@page "/myDome"
<p><span>姓名：</span><input @bind="@pName" /></p>
<p><span>年齡：</span><input @bind-value="@pAge" @bind-value:event="oninput"/></p>
<CascadingValue Value="@pName" Name="ProfileName">
    <CascadingValue Value="@pAge" Name="ProfileAge">
        <ParentComponent />
    </CascadingValue>
</CascadingValue>
@code {
    private string pName { get; set; } = "張三";
    private int pAge { get; set; } = 35;
}

ParentComponent.razor：

<div style="background-color:darkgray;width:200px;">
    <p>Parent Component</p>
    <div style="padding:10px;">
        <p> 年齡 :@Age</p>
        <ChildComponent />
    </div>
</div>
@code{
    [CascadingParameter(Name = "ProfileAge")]
    int Age { get; set; }
}

ChildComponent.razor：

<div style="background-color:beige;width:200px;">
    <p>Child Component</p>
    <p>名稱 : @Name.ToString()</p>
</div>

@code{
    [CascadingParameter(Name = "ProfileName")]
    string Name { get; set; }
}

 運行效果如下：

 

 可以發現，一級直接將二級和三級的組件進行了數據穿透，不過需要注意的是CascadingValue的Name一定要和CascadingParameter的Name相同，否則將會執行錯誤。

五.路由

 　　從古至今，任何大型的開發框架，都是具有路由的，否則可能將會無法工作，其實Blazor的啟動頁也就使用了路由，這是毋庸置疑的。當你的組件帶有 @page 指令時，將為生成的類指定  指定路由模板的。 在運行時，路由器將使用 RouteAttribute 查找組件類，並呈現哪個組件包含與請求的 URL 匹配的路由模板。

@page "/luyou"
@page "/luyou/{text}"

<h1>Blazor is @Text!</h1>

@code {
    [Parameter]
    public string Text { get; set; }

    protected override void OnInitialized()
    {
        Text = Text ?? "fantastic";
    }
}

運行效果如下：

在上面的示例中應用了兩個 @page 指令。 第一個允許導航到沒有參數的組件。 第二個 @page 指令採用 {text} 路由參數，並將該值分配給 Text 屬性。

關於Blazor的基礎入門咱們這篇就說到這裏，相信你一定覺得Blazor了不起！它是一個現代的開源框架。它也由一家擁有悠久歷史的公司擁有，該公司放棄了昨天的閃亮新技術。因此，大多數開發人員都應該謹慎對待Blazor。只要JavaScript能夠執行Blazor可以做的所有事情，而沒有下載大小，性能和新工具堆棧帶來的額外挑戰，大多數開發人員將一如既往。

這並不意味着Blazor不能在所有這些領域都佔有一席之地。它甚至可能成為.NET Web應用程序開發中的主導力量。但是如果我今天必須下注，這就是我要依靠的東西。WebAssembly是未來。但就目前而言，Blazor只是一種有趣的可能性。

六.彩蛋

就現在！我的好朋友宇辰正在開發一款名為Blazui的UI組件。它為什麼叫Blazui？

Blazor + Element UI = Blazui，Element UI 的blazor版本，無JS，無TS，用 .Net 寫前端的 UI 框架，非 Silverlight，非 WebForm，開箱即用！！

Blazui 演示地址：。QQ群：74522853，碼雲地址：

參考Blazor使用的前提條件：

1. 安裝 .Net Core 3.0
2. 安裝 VS2019
3. 安裝所有 VS2019 Blazor Extension

現在Blazor正在逐漸變好，讓我們即刻出發！.NET Core 不只是開源！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

前言

我在看SOFAJRaft的源碼的時候看到了使用了對象池的技術，看了一下感覺要吃透的話還是要新開一篇文章來講，內容也比較充實，大家也可以學到之後運用到實際的項目中去。

這裏我使用RecyclableByteBufferList來作為講解的例子：

RecyclableByteBufferList

public final class RecyclableByteBufferList extends ArrayList<ByteBuffer> implements Recyclable {

    private transient final Recyclers.Handle handle;

    private static final Recyclers<RecyclableByteBufferList> recyclers = new Recyclers<RecyclableByteBufferList>(512) {

        @Override
        protected RecyclableByteBufferList newObject(final Handle handle) {
            return new RecyclableByteBufferList(
                    handle);
        }
    };

      //獲取一個RecyclableByteBufferList實例
    public static RecyclableByteBufferList newInstance(final int minCapacity) {
        final RecyclableByteBufferList ret = recyclers.get();
        //容量不夠的話，進行擴容
        ret.ensureCapacity(minCapacity);
        return ret;
    }
      //回收RecyclableByteBufferList對象
    @Override
    public boolean recycle() {
        clear();
        this.capacity = 0;
        return recyclers.recycle(this, handle);
    }
}

我在上面將RecyclableByteBufferList獲取對象的方法和回收對象的方法給列舉出來了，獲取實例的時候會通過recyclers的get方法去獲取，回收對象的時候會去調用list的clear方法清空list裏面的內容之後再去調用recyclers的recycle方法進行回收。
如果recyclers裏面沒有對象可以獲取，那麼會調用newObject方法創建一個對象，然後將handle對象傳入構造器中進行實例化。

對象池Recyclers

數據結構

1. 每一個 Recyclers 對象包含一個 ThreadLocal<Stack<T>> threadLocal實例；
   每一個線程包含一個 Stack 對象，該 Stack 對象包含一個 DefaultHandle[]，而 DefaultHandle 中有一個屬性 T value，用於存儲真實對象。也就是說，每一個被回收的對象都會被包裝成一個 DefaultHandle 對象
2. 每一個 Recyclers 對象包含一個ThreadLocal<Map<Stack<?>, WeakOrderQueue>> delayedRecycled實例；
   每一個線程對象包含一個 Map<Stack<?>, WeakOrderQueue>，存儲着為其他線程創建的 WeakOrderQueue 對象，WeakOrderQueue 對象中存儲一個以 Head 為首的 Link 數組，每個 Link 對象中存儲一個 DefaultHandle[] 數組，用於存放回收對象。

假設線程A創建的對象

1. 線程A回收RecyclableByteBufferList時，直接將RecyclableByteBufferList的DefaultHandle 對象壓入 Stack 的 DefaultHandle[] 中；
2. 線程B回收RecyclableByteBufferList時，會首先從其 Map<Stack<?>, WeakOrderQueue> 對象中獲取 key=線程A的Stack 對象的 WeakOrderQueue，然後直接將RecyclableByteBufferList的DefaultHandle 對象（內部包含RecyclableByteBufferList對象）壓入該 WeakOrderQueue 中的 Link 鏈表中的尾部 Link 的 DefaultHandle[]中，同時，這個 WeakOrderQueue 會與線程 A 的 Stack 中的 head 屬性進行關聯，用於後續對象的 pop 操作；
3. 當線程 A 從對象池獲取對象時，如果線程 A 的 Stack 中有對象，則直接彈出；如果沒有對象，則先從其 head 屬性所指向的 WeakorderQueue 開始遍歷 queue 鏈表，將 RecyclableByteBufferList 對象從其他線程的 WeakOrderQueue 中轉移到線程 A 的 Stack 中（一次 pop 操作只轉移一個包含了元素的 Link），再彈出。

Recyclers靜態代碼塊

private static final int DEFAULT_INITIAL_MAX_CAPACITY_PER_THREAD = 4 * 1024; // Use 4k instances as default.
private static final int DEFAULT_MAX_CAPACITY_PER_THREAD;
private static final int INITIAL_CAPACITY;

static {
    // 每個線程的最大對象池容量
    int maxCapacityPerThread = SystemPropertyUtil.getInt("jraft.recyclers.maxCapacityPerThread", DEFAULT_INITIAL_MAX_CAPACITY_PER_THREAD);
    if (maxCapacityPerThread < 0) {
        maxCapacityPerThread = DEFAULT_INITIAL_MAX_CAPACITY_PER_THREAD;
    }

    DEFAULT_MAX_CAPACITY_PER_THREAD = maxCapacityPerThread;
    if (LOG.isDebugEnabled()) {
        if (DEFAULT_MAX_CAPACITY_PER_THREAD == 0) {
            LOG.debug("-Djraft.recyclers.maxCapacityPerThread: disabled");
        } else {
            LOG.debug("-Djraft.recyclers.maxCapacityPerThread: {}", DEFAULT_MAX_CAPACITY_PER_THREAD);
        }
    }
    // 設置初始化容量信息
    INITIAL_CAPACITY = Math.min(DEFAULT_MAX_CAPACITY_PER_THREAD, 256);
}

 public static final Handle NOOP_HANDLE = new Handle() {};

Recyclers會在靜態代碼塊中做一些對象池容量初始化的工作，初始化了最大對象池容量和初始化容量信息。

從對象池中獲取對象

Recyclers#get

// 線程變量，保存每個線程的對象池信息，通過 ThreadLocal 的使用，避免了不同線程之間的競爭情況
private final ThreadLocal<Stack<T>> threadLocal = new ThreadLocal<Stack<T>>() {

    @Override
    protected Stack<T> initialValue() {
        return new Stack<>(Recyclers.this, Thread.currentThread(), maxCapacityPerThread);
    }
};

public final T get() {
    if (maxCapacityPerThread == 0) {
        return newObject(NOOP_HANDLE);
    }
    //從threadLocal中獲取一個棧對象
    Stack<T> stack = threadLocal.get();
    //拿出棧頂元素
    DefaultHandle handle = stack.pop();
    //如果棧裏面沒有元素，那麼就實例化一個
    if (handle == null) {
        handle = stack.newHandle();
        handle.value = newObject(handle);
    }
    return (T) handle.value;
}

Get方法會從threadLocal中去獲取數據，如果獲取不到，那麼會初始化一個Stack，並傳入當前Recyclers實例，當前線程，與最大容量。然後從stack中pop拿出棧頂元素，如果獲取的元素為空，那麼直接調用newHandle新建一個DefaultHandle實例，並調用Recyclers實現類的newObject獲取實現類的實例。也就是說DefaultHandle是用來封裝真正的對象的實例。

從stack中申請一個對象

Stack(Recyclers<T> parent, Thread thread, int maxCapacity) {
    this.parent = parent;
    this.thread = thread;
    this.maxCapacity = maxCapacity;
    elements = new DefaultHandle[Math.min(INITIAL_CAPACITY, maxCapacity)];
}

DefaultHandle pop() {
    int size = this.size;
    if (size == 0) {
        if (!scavenge()) {
            return null;
        }
        size = this.size;
    }
    //size表示整個stack中的大小
    size--;
    //獲取最後一個元素
    DefaultHandle ret = elements[size];
    if (ret.lastRecycledId != ret.recycleId) {
        throw new IllegalStateException("recycled multiple times");
    }
    // 清空回收信息，以便判斷是否重複回收
    ret.recycleId = 0;
    ret.lastRecycledId = 0;
    this.size = size;
    return ret;
}

獲取對象的邏輯也比較簡單，當 Stack 中的 DefaultHandle[] 的 size 為 0 時，需要從其他線程的 WeakOrderQueue 中轉移數據到 Stack 中的 DefaultHandle[]，即 scavenge方法，該方法下面再聊。當 Stack 中的 DefaultHandle[] 中最終有了數據時，直接獲取最後一個元素

對象池回收對象

我們再來看看RecyclableByteBufferList是怎麼回收對象的。
RecyclableByteBufferList#recycle

public boolean recycle() {
    clear();
    this.capacity = 0;
    return recyclers.recycle(this, handle);
}

RecyclableByteBufferList回收對象的時候首先會調用clear方法清空屬性，然後調用recyclers的recycle方法進行對象回收。

Recyclers#recycle

public final boolean recycle(T o, Handle handle) {
    if (handle == NOOP_HANDLE) {
        return false;
    }

    DefaultHandle h = (DefaultHandle) handle;
    //stack在實例化的時候會在構造器中傳入一個Recyclers作為parent
    //所以這裡是校驗一下，如果不是當前線程的, 直接不回收了
    if (h.stack.parent != this) {
        return false;
    }
    if (o != h.value) {
        throw new IllegalArgumentException("o does not belong to handle");
    }
    h.recycle();
    return true;
}

這裡會接着調用DefaultHandle的recycle方法進行回收

DefaultHandle

static final class DefaultHandle implements Handle {
    //在WeakOrderQueue的add方法中會設置成ID
    //在push方法中設置成為OWN_THREAD_ID
    //在pop方法中設置為0
    private int lastRecycledId;
    //只有在push方法中才會設置OWN_THREAD_ID
    //在pop方法中設置為0
    private int recycleId;
    //當前的DefaultHandle對象所屬的Stack
    private Stack<?> stack;
    private Object value;

    DefaultHandle(Stack<?> stack) {
        this.stack = stack;
    }

    public void recycle() {
        Thread thread = Thread.currentThread();
        //如果當前線程正好等於stack所對應的線程，那麼直接push進去
        if (thread == stack.thread) {
            stack.push(this);
            return;
        }
        // we don't want to have a ref to the queue as the value in our weak map
        // so we null it out; to ensure there are no races with restoring it later
        // we impose a memory ordering here (no-op on x86)
        // 如果不是當前線程，則需要延遲回收，獲取當前線程存儲的延遲回收WeakHashMap
        Map<Stack<?>, WeakOrderQueue> delayedRecycled = Recyclers.delayedRecycled.get();
        // 當前 handler 所在的 stack 是否已經在延遲回收的任務隊列中
        // 並且 WeakOrderQueue是一個多線程間可以共享的Queue
        WeakOrderQueue queue = delayedRecycled.get(stack);
        if (queue == null) {
            delayedRecycled.put(stack, queue = new WeakOrderQueue(stack, thread));
        }
        queue.add(this);
    }
}

DefaultHandle在實例化的時候會傳入一個stack實例，代表當前實例是屬於這個stack的。
所以在調用recycle方法的時候，會判斷一下，當前的線程是不是stack所屬的線程，如果是那麼直接push到stack裏面就好了，不是則調用延遲隊列delayedRecycled；
從delayedRecycled隊列中獲取Map<Stack<?>, WeakOrderQueue> delayedRecycled ，根據stack作為key來獲取WeakOrderQueue，然後將當前的DefaultHandle實例放入到WeakOrderQueue中。

同線程回收對象

Stack#push

void push(DefaultHandle item) {
    // (item.recycleId | item.lastRecycleId) != 0 等價於 item.recycleId!=0 && item.lastRecycleId!=0
    // 當item開始創建時item.recycleId==0 && item.lastRecycleId==0
    // 當item被recycle時，item.recycleId==x，item.lastRecycleId==y 進行賦值
    // 當item被pop之後， item.recycleId = item.lastRecycleId = 0
    // 所以當item.recycleId 和 item.lastRecycleId 任何一個不為0，則表示回收過
    if ((item.recycleId | item.lastRecycledId) != 0) {
        throw new IllegalStateException("recycled already");
    }
    // 設置對象的回收id為線程id信息，標記自己的被回收的線程信息
    item.recycleId = item.lastRecycledId = OWN_THREAD_ID;

    int size = this.size;
    if (size >= maxCapacity) {
        // Hit the maximum capacity - drop the possibly youngest object.
        return;
    }
    // stack中的elements擴容兩倍，複製元素，將新數組賦值給stack.elements
    if (size == elements.length) {
        elements = Arrays.copyOf(elements, Math.min(size << 1, maxCapacity));
    }

    elements[size] = item;
    this.size = size + 1;
}

同線程回收對象 DefaultHandle#recycle 步驟：

1. stack 先檢測當前的線程是否是創建 stack 的線程，如果不是，則走異線程回收邏輯；如果是，則首先判斷是否重複回收，然後判斷 stack 的 DefaultHandle[] 中的元素個數是否已經超過最大容量（4k），如果是，直接返回；
2. 判斷當前的 DefaultHandle[] 是否還有空位，如果沒有，以 maxCapacity 為最大邊界擴容 2 倍，之後拷貝舊數組的元素到新數組，然後將當前的 DefaultHandle 對象放置到 DefaultHandle[] 中
3. 最後重置 stack.size 屬性

異線程回收對象

WeakOrderQueue

static final class Stack<T> {
    //使用volatile可以立即讀取到該queue
      private volatile WeakOrderQueue head;
}
WeakOrderQueue(Stack<?> stack, Thread thread) {
    head = tail = new Link();
    //使用的是WeakReference ，作用是在poll的時候，如果owner不存在了
    // 則需要將該線程所包含的WeakOrderQueue的元素釋放，然後從鏈表中刪除該Queue。
    owner = new WeakReference<>(thread);
    //假設線程B和線程C同時回收線程A的對象時，有可能會同時創建一個WeakOrderQueue，就坑同時設置head，所以這裏需要加鎖
    synchronized (stackLock(stack)) {
        next = stack.head;
        stack.head = this;
    }
}

創建WeakOrderQueue對象的時候會初始化一個WeakReference的owner，作用是在poll的時候，如果owner不存在了， 則需要將該線程所包含的WeakOrderQueue的元素釋放，然後從鏈表中刪除該Queue。

然後給stack加鎖，假設線程B和線程C同時回收線程A的對象時，有可能會同時創建一個WeakOrderQueue，就坑同時設置head，所以這裏需要加鎖。

以head==null的時候為例
加鎖：
線程B先執行，則head = 線程B的queue；之後線程C執行，此時將當前的head也就是線程B的queue作為線程C的queue的next，組成鏈表，之後設置head為線程C的queue
不加鎖：
線程B先執行 next = stack.head此時線程B的queue.next=null->線程C執行next = stack.head;線程C的queue.next=null-> 線程B執行stack.head = this;設置head為線程B的queue -> 線程C執行stack.head = this;設置head為線程C的queue，此時線程B和線程C的queue沒有連起來。

WeakOrderQueue#add

void add(DefaultHandle handle) {
    // 設置handler的最近一次回收的id信息，標記此時暫存的handler是被誰回收的
    handle.lastRecycledId = id;

    Link tail = this.tail;
    int writeIndex;
    // 判斷一個Link對象是否已經滿了：
    // 如果沒滿，直接添加；
    // 如果已經滿了，創建一個新的Link對象，之後重組Link鏈表，然後添加元素的末尾的Link（除了這個Link，前邊的Link全部已經滿了）
    if ((writeIndex = tail.get()) == LINK_CAPACITY) {
        this.tail = tail = tail.next = new Link();
        writeIndex = tail.get();
    }
    tail.elements[writeIndex] = handle;
    // 如果使用者在將DefaultHandle對象壓入隊列后，將Stack設置為null
    // 但是此處的DefaultHandle是持有stack的強引用的，則Stack對象無法回收；
    //而且由於此處DefaultHandle是持有stack的強引用，WeakHashMap中對應stack的WeakOrderQueue也無法被回收掉了，導致內存泄漏
    handle.stack = null;
    // we lazy set to ensure that setting stack to null appears before we unnull it in the owning thread;
    // this also means we guarantee visibility of an element in the queue if we see the index updated
    // tail本身繼承於AtomicInteger，所以此處直接對tail進行+1操作
    tail.lazySet(writeIndex + 1);
}

Stack異線程push對象流程：

1. 首先獲取當前線程的 Map<Stack<?>, WeakOrderQueue> 對象，如果沒有就創建一個空 map；
2. 然後從 map 對象中獲取 key 為當前的 Stack 對象的 WeakOrderQueue；
3. 如果獲取的WeakOrderQueue對象為null，那麼創建一個WeakOrderQueue對象，並將對象放入到map中，最後調用WeakOrderQueue#add添加對象

WeakOrderQueue 的創建流程：

1. 創建一個Link對象，將head和tail的引用都設置為此對象
2. 創建一個WeakReference指向owner對象，設置當前的 WeakOrderQueue 所屬的線程為當前線程。
3. 先將原本的 stack.head 賦值給剛剛創建的 WeakOrderQueue 的 next 節點，之後將剛剛創建的 WeakOrderQueue 設置為 stack.head（這一步非常重要：假設線程 A 創建對象，此處是線程 C 回收對象，則線程 C 先獲取其 Map<Stack<?>, WeakOrderQueue> 對象中 key=線程A的stack對象的 WeakOrderQueue，然後將該 Queue 賦值給線程 A 的 stack.head，後續的 pop 操作打基礎），形成 WeakOrderQueue 的鏈表結構。

WeakOrderQueue#add添加對象流程

1. 首先設置 item.lastRecycledId = 當前 WeakOrderQueue 的 id
2. 然後看當前的 WeakOrderQueue 中的 Link 節點鏈表中的尾部 Link 節點的 DefaultHandle[] 中的元素個數是否已經達到 LINK_CAPACITY（16）
3. 如果不是，則直接將當前的 DefaultHandle 元素插入尾部 Link 節點的 DefaultHandle[] 中，之後置空當前的 DefaultHandle 元素的 stack 屬性，最後記錄當前的 DefaultHandle[] 中的元素數量；
4. 如果是，則新建一個 Link，並且放在當前的 Link 鏈表中的尾部節點處，與之前的 tail 節點連起來（鏈表），之後進行第三步的操作。

從異線程獲取對象

我再把pop方法搬下來一次：

DefaultHandle pop() {
    int size = this.size;
    // size=0 則說明本線程的Stack沒有可用的對象，先從其它線程中獲取。
    if (size == 0) {
        // 當 Stack<T> 此時的容量為 0 時，去 WeakOrder 中轉移部分對象到 Stack 中
        if (!scavenge()) {
            return null;
        }
        //由於在transfer(Stack<?> dst)的過程中，可能會將其他線程的WeakOrderQueue中的DefaultHandle對象傳遞到當前的Stack,
        //所以size發生了變化，需要重新賦值
        size = this.size;
    }
    //size表示整個stack中的大小
    size--;
    //獲取最後一個元素
    DefaultHandle ret = elements[size];
    if (ret.lastRecycledId != ret.recycleId) {
        throw new IllegalStateException("recycled multiple times");
    }
    // 清空回收信息，以便判斷是否重複回收
    ret.recycleId = 0;
    ret.lastRecycledId = 0;
    this.size = size;
    return ret;
}

1. 首先獲取當前的 Stack 中的 DefaultHandle 對象中的元素個數。
2. 如果為 0，則從其他線程的與當前的 Stack 對象關聯的 WeakOrderQueue 中獲取元素，並轉移到 Stack 的 DefaultHandle[] 中（每一次 pop 只轉移一個有元素的 Link），如果轉移不成功，說明沒有元素可用，直接返回 null；
3. 如果轉移成功，則重置 size屬性 = 轉移后的 Stack 的 DefaultHandle[] 的 size，之後直接獲取 Stack 對象中 DefaultHandle[] 的最後一位元素，之後做防護性檢測，最後重置當前的 stack 對象的 size 屬性以及獲取到的 DefaultHandle 對象的 recycledId 和 lastRecycledId 回收標記，返回 DefaultHandle 對象。

scavenge轉移

Stack#scavenge

boolean scavenge() {
    // continue an existing scavenge, if any
    // 掃描判斷是否存在可轉移的 Handler
    if (scavengeSome()) {
        return true;
    }
    
    // reset our scavenge cursor
    prev = null;
    cursor = head;
    return false;
}

調用scavengeSome掃描判斷是否存在可轉移的 Handler，如果沒有，那麼就返回false，表示沒有可用對象

Stack#scavengeSome

boolean scavengeSome() {
    WeakOrderQueue cursor = this.cursor;
    if (cursor == null) {
        cursor = head;
        // 如果head==null，表示當前的Stack對象沒有WeakOrderQueue，直接返回
        if (cursor == null) {
            return false;
        }
    }

    boolean success = false;
    WeakOrderQueue prev = this.prev;
    do {
        // 從當前的WeakOrderQueue節點進行 handler 的轉移
        if (cursor.transfer(this)) {
            success = true;
            break;
        }
        // 遍歷下一個WeakOrderQueue
        WeakOrderQueue next = cursor.next;
        // 如果 WeakOrderQueue 的實際持有線程因GC回收了
        if (cursor.owner.get() == null) {
            // If the thread associated with the queue is gone, unlink it, after
            // performing a volatile read to confirm there is no data left to collect.
            // We never unlink the first queue, as we don't want to synchronize on updating the head.
            // 如果當前的WeakOrderQueue的線程已經不可達了
            //如果該WeakOrderQueue中有數據，則將其中的數據全部轉移到當前Stack中
            if (cursor.hasFinalData()) {
                for (;;) {
                    if (cursor.transfer(this)) {
                        success = true;
                    } else {
                        break;
                    }
                }
            }
            //將當前的WeakOrderQueue的前一個節點prev指向當前的WeakOrderQueue的下一個節點，
            // 即將當前的WeakOrderQueue從Queue鏈表中移除。方便後續GC
            if (prev != null) {
                prev.next = next;
            }
        } else {
            prev = cursor;
        }

        cursor = next;

    } while (cursor != null && !success);

    this.prev = prev;
    this.cursor = cursor;
    return success;
}

1. 首先設置當前操作的 WeakOrderQueue cursor，如果為 null，則賦值為 stack.head 節點，如果 stack.head 為 null，則表明外部線程沒有回收過當前線程創建的 對象，外部線程在回收對象的時候會創建一個WeakOrderQueue，並將stack.head 指向新創建的WeakOrderQueue對象，則直接返回 false；如果不為 null，則繼續向下執行；
2. 首先對當前的 cursor 進行元素的轉移，如果轉移成功，則跳出循環，設置 prev 和 cursor 屬性；
3. 如果轉移不成功，獲取下一個線程 Y 中的與當前線程的 Stack 對象關聯的 WeakOrderQueue，如果該 queue 所屬的線程 Y 還可達，則直接設置 cursor 為該 queue，進行下一輪循環；如果該 queue 所屬的線程 Y 不可達了，則判斷其內是否還有元素，如果有，全部轉移到當前線程的 Stack 中，之後將線程 Y 的 queue 從查詢 queue 鏈表中移除。

transfer轉移

    boolean transfer(Stack<?> dst) {
        //尋找第一個Link
        Link head = this.head;
        // head == null，沒有存儲數據的節點，直接返回
        if (head == null) {
            return false;
        }
        // 讀指針的位置已經到達了每個 Node 的存儲容量，如果還有下一個節點，進行節點轉移
        if (head.readIndex == LINK_CAPACITY) {
            //判斷當前的Link節點的下一個節點是否為null，如果為null，說明已經達到了Link鏈表尾部，直接返回，
            if (head.next == null) {
                return false;
            }
            // 否則，將當前的Link節點的下一個Link節點賦值給head和this.head.link，進而對下一個Link節點進行操作
            this.head = head = head.next;
        }
        // 獲取Link節點的readIndex,即當前的Link節點的第一個有效元素的位置
        final int srcStart = head.readIndex;
        // 獲取Link節點的writeIndex，即當前的Link節點的最後一個有效元素的位置
        int srcEnd = head.get();
        // 本次可轉移的對象數量（寫指針減去讀指針）
        final int srcSize = srcEnd - srcStart;
        if (srcSize == 0) {
            return false;
        }
        // 獲取轉移元素的目的地Stack中當前的元素個數
        final int dstSize = dst.size;
        // 計算期盼的容量
        final int expectedCapacity = dstSize + srcSize;
        // 期望的容量大小與實際 Stack 所能承載的容量大小進行比對，取最小值
        if (expectedCapacity > dst.elements.length) {
            final int actualCapacity = dst.increaseCapacity(expectedCapacity);
            srcEnd = Math.min(srcStart + actualCapacity - dstSize, srcEnd);
        }

        if (srcStart != srcEnd) {
            // 獲取Link節點的DefaultHandle[]
            final DefaultHandle[] srcElems = head.elements;
            // 獲取目的地Stack的DefaultHandle[]
            final DefaultHandle[] dstElems = dst.elements;
            // dst數組的大小，會隨着元素的遷入而增加，如果最後發現沒有增加，那麼表示沒有遷移成功任何一個元素
            int newDstSize = dstSize;
            //// 進行對象轉移
            for (int i = srcStart; i < srcEnd; i++) {
                DefaultHandle element = srcElems[i];
                // 表明自己還沒有被任何一個 Stack 所回收
                if (element.recycleId == 0) {
                    element.recycleId = element.lastRecycledId;
                //  避免對象重複回收
                } else if (element.recycleId != element.lastRecycledId) {
                    throw new IllegalStateException("recycled already");
                }
                // 將可轉移成功的DefaultHandle元素的stack屬性設置為目的地Stack
                element.stack = dst;
                // 將DefaultHandle元素轉移到目的地Stack的DefaultHandle[newDstSize ++]中
                dstElems[newDstSize++] = element;
                // 設置為null，清楚暫存的handler信息，同時幫助 GC
                srcElems[i] = null;
            }
            // 將新的newDstSize賦值給目的地Stack的size
            dst.size = newDstSize;

            if (srcEnd == LINK_CAPACITY && head.next != null) {
                // 將Head指向下一個Link，也就是將當前的Link給回收掉了
                // 假設之前為Head -> Link1 -> Link2，回收之後為Head -> Link2
                this.head = head.next;
            }
            // 設置讀指針位置
            head.readIndex = srcEnd;
            return true;
        } else {
            // The destination stack is full already.
            return false;
        }
    }
}

1. 尋找 cursor 節點中的第一個 Link如果為 null，則表示沒有數據，直接返回；
2. 如果第一個 Link 節點的 readIndex 索引已經到達該 Link 對象的 DefaultHandle[] 的尾部，則判斷當前的 Link 節點的下一個節點是否為 null，如果為 null，說明已經達到了 Link 鏈表尾部，直接返回，否則，將當前的 Link 節點的下一個 Link 節點賦值給 head ，進而對下一個 Link 節點進行操作；
3. 獲取 Link 節點的 readIndex，即當前的 Link 節點的第一個有效元素的位置
4. 獲取 Link 節點的 writeIndex，即當前的 Link 節點的最後一個有效元素的位置
5. 計算 Link 節點中可以被轉移的元素個數，如果為 0，表示沒有可轉移的元素，直接返回
6. 獲取轉移元素的目標 Stack 中當前的元素個數（dstSize）並計算期盼的容量 expectedCapacity，如果 expectedCapacity 大於目標Stack 的長度（dst.elements.length），則先對目的地 Stack 進行擴容，計算 Link 中最終的可轉移的最後一個元素的下標；
7. 如果發現目的地 Stack 已經滿了（ srcStart ！= srcEnd為false），則直接返回 false
8. 獲取 Link 節點的 DefaultHandle[] （srcElems）和目標 Stack 的 DefaultHandle[]（dstElems）
9. 根據可轉移的起始位置和結束位置對 Link 節點的 DefaultHandle[] 進行循環操作
10. 將可轉移成功的 DefaultHandle 元素的stack屬性設置為目標 Stack（element.stack = dst），將 DefaultHandle 元素轉移到目的地 Stack 的 DefaultHandle[newDstSize++] 中，最後置空 Link 節點的 DefaultHandle[i]
11. 如果當前被遍歷的 Link 節點的 DefaultHandle[] 已經被掏空了（srcEnd == LINK_CAPACITY），並且該 Link 節點還有下一個 Link 節點
12. 重置當前 Link 的 readIndex

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"

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

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

前言

          Saga單詞翻譯過來是指尤指古代挪威或冰島講述冒險經歷和英雄業績的長篇故事，對，這裏強調長篇故事。許多系統都存在長時間運行的業務流程，NServiceBus使用基於事件驅動的體繫結構將容錯性和可伸縮性融入這些業務處理過程中。
          當然一個單一接口調用則算不上一個長時間運行的業務場景，那麼如果在給定的用例中有兩個或多個調用，則應該考慮數據一致性的問題，這裡有可能第一個接口調用成功，第二次調用則可能失敗或者超時，Saga的設計以簡單而健壯的方式處理這樣的業務用例。

認識Saga

         先來通過一段代碼簡單認識一下Saga，在NServiceBus里，使用Saga的話則需要實現抽象類Saga ，SqlSaga ，這裏的T的是Saga業務實體，封裝數據，用來在長時間運行過程中封裝業務數據。

public class Saga:Saga<State>,
        IAmStartedByMessages<StartOrder>,
        IHandleMessages<CompleteOrder>
    {
        protected override void ConfigureHowToFindSaga(SagaPropertyMapper<State> mapper)
        {
            mapper.ConfigureMapping<StartOrder>(message=>message.OrderId).ToSaga(saga=>saga.OrderId);
            mapper.ConfigureMapping<CompleteOrder>(message=>message.OrderId).ToSaga(saga=>saga.OrderId);
        }

        public Task Handle(StartOrder message, IMessageHandlerContext context)
        {
            return Task.CompletedTask;
        }

        public Task Handle(CompleteOrder message, IMessageHandlerContext context)
        {
            MarkAsComplete();
            return Task.CompletedTask;
        }
    }

臨時狀態

     長時間運行則意味着有狀態，任何涉及多個網絡調用的進程都需要一個臨時狀態，這個臨時狀態可以存儲在內存中，序列化在磁盤中，也可以存儲在分佈式緩存中。在NServiceBus中我們定義實體，繼承抽象類ContainSagaData即可，默認情況下，所有公開訪問的屬性都會被持久化。

public class State:ContainSagaData
{
    public Guid OrderId { get; set; }
}

添加行為

      在NServiceBus里，處理消息的有兩種接口：IHandlerMessages 、IAmStartedByMessages 。

開啟一個Saga

       在前面的代碼片段里，我們看到已經實現了接口IAmStartedByMessages ，這個接口告訴NServiceBus，如果收到了StartOrder 消息，則創建一個Saga實例（Saga Instance），當然Saga長流程處理的實體至少有一個需要開啟Saga流程。

處理無序消息

       如果你的業務用例中確實存在無序消息的情況，則還需要業務流程正常輪轉，那麼則需要多個messaeg都要事先接口IAmStartedByMessages接口，也就是說多個message都可以創建Saga實例。

依賴可恢復性

      在處理無序消息和多個消息類型的時候，就存在消息丟失的可能，必須在你的Saga狀態完成以後，這個Saga實例又收到一條消息，但這時Saga狀態已經是完結狀態，這條消息則仍然需要處理，這裏則實現NServiceBus的IHandleSagaNotFound接口。

 public class SagaNotFoundHandler:IHandleSagaNotFound
 {
    public Task Handle(object message, IMessageProcessingContext context)
    {
        return context.Reply(new SagaNotFoundMessage());
    }
 }
  
 public class SagaNotFoundMessage
 {
        
 }

結束Saga

      當你的業務用例不再需要Saga實例時，則調用MarkComplete()來結束Saga實例。這個方法在前面的代碼片段中也可以看到，其實本質也就是設置Saga.Complete屬性，這是個bool值，你在業務用例中也可以用此值來判斷Saga流程是否結束。

namespace NServiceBus
{
    using System;
    using System.Threading.Tasks;
    using Extensibility;

    public abstract class Saga
    {
        /// <summary>
        /// The saga's typed data.
        /// </summary>
        public IContainSagaData Entity { get; set; }

        
        public bool Completed { get; private set; }

        internal protected abstract void ConfigureHowToFindSaga(IConfigureHowToFindSagaWithMessage sagaMessageFindingConfiguration);

       
        protected Task RequestTimeout<TTimeoutMessageType>(IMessageHandlerContext context, DateTime at) where TTimeoutMessageType : new()
        {
            return RequestTimeout(context, at, new TTimeoutMessageType());
        }

        
        protected Task RequestTimeout<TTimeoutMessageType>(IMessageHandlerContext context, DateTime at, TTimeoutMessageType timeoutMessage)
        {
            if (at.Kind == DateTimeKind.Unspecified)
            {
                throw new InvalidOperationException("Kind property of DateTime 'at' must be specified.");
            }

            VerifySagaCanHandleTimeout(timeoutMessage);

            var options = new SendOptions();

            options.DoNotDeliverBefore(at);
            options.RouteToThisEndpoint();

            SetTimeoutHeaders(options);

            return context.Send(timeoutMessage, options);
        }

        
        protected Task RequestTimeout<TTimeoutMessageType>(IMessageHandlerContext context, TimeSpan within) where TTimeoutMessageType : new()
        {
            return RequestTimeout(context, within, new TTimeoutMessageType());
        }

        
        protected Task RequestTimeout<TTimeoutMessageType>(IMessageHandlerContext context, TimeSpan within, TTimeoutMessageType timeoutMessage)
        {
            VerifySagaCanHandleTimeout(timeoutMessage);

            var sendOptions = new SendOptions();

            sendOptions.DelayDeliveryWith(within);
            sendOptions.RouteToThisEndpoint();

            SetTimeoutHeaders(sendOptions);

            return context.Send(timeoutMessage, sendOptions);
        }

        
        protected Task ReplyToOriginator(IMessageHandlerContext context, object message)
        {
            if (string.IsNullOrEmpty(Entity.Originator))
            {
                throw new Exception("Entity.Originator cannot be null. Perhaps the sender is a SendOnly endpoint.");
            }

            var options = new ReplyOptions();

            options.SetDestination(Entity.Originator);
            context.Extensions.Set(new AttachCorrelationIdBehavior.State { CustomCorrelationId = Entity.OriginalMessageId });

            
            options.Context.Set(new PopulateAutoCorrelationHeadersForRepliesBehavior.State
            {
                SagaTypeToUse = null,
                SagaIdToUse = null
            });

            return context.Reply(message, options);
        }

        //這個方法結束saga流程，標記Completed屬性
        protected void MarkAsComplete()
        {
            Completed = true;
        }

        void VerifySagaCanHandleTimeout<TTimeoutMessageType>(TTimeoutMessageType timeoutMessage)
        {
            var canHandleTimeoutMessage = this is IHandleTimeouts<TTimeoutMessageType>;
            if (!canHandleTimeoutMessage)
            {
                var message = $"The type '{GetType().Name}' cannot request timeouts for '{timeoutMessage}' because it does not implement 'IHandleTimeouts<{typeof(TTimeoutMessageType).FullName}>'";
                throw new Exception(message);
            }
        }

        void SetTimeoutHeaders(ExtendableOptions options)
        {
            options.SetHeader(Headers.SagaId, Entity.Id.ToString());
            options.SetHeader(Headers.IsSagaTimeoutMessage, bool.TrueString);
            options.SetHeader(Headers.SagaType, GetType().AssemblyQualifiedName);
        }
    }
}

    

Saga持久化

      本機開發環境我們使用LearningPersistence，但是投產的話則需要使用數據庫持久化，這裏我們基於MySQL，SQL持久化需要引入NServiceBus.Persistence.Sql。SQL Persistence會生成幾種關係型數據庫的sql scripts，然後會根據你的斷言配置選擇所需數據庫，比如SQL Server、MySQL、PostgreSQL、Oracle。
     持久化Saga自動創建所需表結構，你只需手動配置即可，配置后編譯成功後項目執行目錄下會生成sql腳本，文件夾名稱是NServiceBus.Persistence.Sql，下面會有Saga子目錄。

/* TableNameVariable */

set @tableNameQuoted = concat('`', @tablePrefix, 'Saga`');
set @tableNameNonQuoted = concat(@tablePrefix, 'Saga');


/* Initialize */

drop procedure if exists sqlpersistence_raiseerror;
create procedure sqlpersistence_raiseerror(message varchar(256))
begin
signal sqlstate
    'ERROR'
set
    message_text = message,
    mysql_errno = '45000';
end;

/* CreateTable */

set @createTable = concat('
    create table if not exists ', @tableNameQuoted, '(
        Id varchar(38) not null,
        Metadata json not null,
        Data json not null,
        PersistenceVersion varchar(23) not null,
        SagaTypeVersion varchar(23) not null,
        Concurrency int not null,
        primary key (Id)
    ) default charset=ascii;
');
prepare script from @createTable;
execute script;
deallocate prepare script;

/* AddProperty OrderId */

select count(*)
into @exist
from information_schema.columns
where table_schema = database() and
      column_name = 'Correlation_OrderId' and
      table_name = @tableNameNonQuoted;

set @query = IF(
    @exist <= 0,
    concat('alter table ', @tableNameQuoted, ' add column Correlation_OrderId varchar(38) character set ascii'), 'select \'Column Exists\' status');

prepare script from @query;
execute script;
deallocate prepare script;

/* VerifyColumnType Guid */

set @column_type_OrderId = (
  select concat(column_type,' character set ', character_set_name)
  from information_schema.columns
  where
    table_schema = database() and
    table_name = @tableNameNonQuoted and
    column_name = 'Correlation_OrderId'
);

set @query = IF(
    @column_type_OrderId <> 'varchar(38) character set ascii',
    'call sqlpersistence_raiseerror(concat(\'Incorrect data type for Correlation_OrderId. Expected varchar(38) character set ascii got \', @column_type_OrderId, \'.\'));',
    'select \'Column Type OK\' status');

prepare script from @query;
execute script;
deallocate prepare script;

/* WriteCreateIndex OrderId */

select count(*)
into @exist
from information_schema.statistics
where
    table_schema = database() and
    index_name = 'Index_Correlation_OrderId' and
    table_name = @tableNameNonQuoted;

set @query = IF(
    @exist <= 0,
    concat('create unique index Index_Correlation_OrderId on ', @tableNameQuoted, '(Correlation_OrderId)'), 'select \'Index Exists\' status');

prepare script from @query;
execute script;
deallocate prepare script;

/* PurgeObsoleteIndex */

select concat('drop index ', index_name, ' on ', @tableNameQuoted, ';')
from information_schema.statistics
where
    table_schema = database() and
    table_name = @tableNameNonQuoted and
    index_name like 'Index_Correlation_%' and
    index_name <> 'Index_Correlation_OrderId' and
    table_schema = database()
into @dropIndexQuery;
select if (
    @dropIndexQuery is not null,
    @dropIndexQuery,
    'select ''no index to delete'';')
    into @dropIndexQuery;

prepare script from @dropIndexQuery;
execute script;
deallocate prepare script;

/* PurgeObsoleteProperties */

select concat('alter table ', table_name, ' drop column ', column_name, ';')
from information_schema.columns
where
    table_schema = database() and
    table_name = @tableNameNonQuoted and
    column_name like 'Correlation_%' and
    column_name <> 'Correlation_OrderId'
into @dropPropertiesQuery;

select if (
    @dropPropertiesQuery is not null,
    @dropPropertiesQuery,
    'select ''no property to delete'';')
    into @dropPropertiesQuery;

prepare script from @dropPropertiesQuery;
execute script;
deallocate prepare script;

/* CompleteSagaScript */

生成的表結構：

持久化配置

      Saga持久化需要依賴NServiceBus.Persistence.Sql。引入后需要實現SqlSaga抽象類，抽象類需要重寫ConfigureMapping，配置Saga工作流程業務主鍵。

public class Saga:SqlSaga<State>,
        IAmStartedByMessages<StartOrder>
{
   protected override void ConfigureMapping(IMessagePropertyMapper mapper)
   {
      mapper.ConfigureMapping<StartOrder>(message=>message.OrderId);
   }

   protected override string CorrelationPropertyName => nameof(StartOrder.OrderId);

   public Task Handle(StartOrder message, IMessageHandlerContext context)
   {
       Console.WriteLine($"Receive message with OrderId:{message.OrderId}");

       MarkAsComplete();
       return Task.CompletedTask;
    }
 }
    
 static async Task MainAsync()
 {
     Console.Title = "Client-UI";

     var configuration = new EndpointConfiguration("Client-UI");
     //這個方法開啟自動建表、自動創建RabbitMQ隊列
     configuration.EnableInstallers(); 
     configuration.UseSerialization<NewtonsoftSerializer>();
     configuration.UseTransport<LearningTransport>();

     string connectionString = "server=127.0.0.1;uid=root;pwd=000000;database=nservicebus;port=3306;AllowUserVariables=True;AutoEnlist=false";
     var persistence = configuration.UsePersistence<SqlPersistence>();
     persistence.SqlDialect<SqlDialect.MySql>();
     //配置mysql連接串
     persistence.ConnectionBuilder(()=>new MySqlConnection(connectionString));

     var instance = await Endpoint.Start(configuration).ConfigureAwait(false);

     var command = new StartOrder()
     {
         OrderId = Guid.NewGuid()
     };

     await instance.SendLocal(command).ConfigureAwait(false);

     Console.ReadKey();

     await instance.Stop().ConfigureAwait(false);
 }

     

Saga Timeouts

     在消息驅動類型的環境中，雖然傳遞的無連接特性可以防止在線等待過程中消耗資源，但是畢竟等待時間需要有一個上線。在NServiceBus里已經提供了Timeout方法，我們只需訂閱即可，可以在你的Handle方法中根據需要訂閱Timeout，可參考如下代碼：

public class Saga:Saga<State>,
        IAmStartedByMessages<StartOrder>,
        IHandleMessages<CompleteOrder>,
        IHandleTimeouts<TimeOutMessage>
    {
        
        public Task Handle(StartOrder message, IMessageHandlerContext context)
        {
            var model=new TimeOutMessage();
            
            //訂閱超時消息
            return RequestTimeout(context,TimeSpan.FromMinutes(10));
        }

        public Task Handle(CompleteOrder message, IMessageHandlerContext context)
        {
            MarkAsComplete();
            return Task.CompletedTask;
        }

        protected override string CorrelationPropertyName => nameof(StartOrder.OrderId);


        public Task Timeout(TimeOutMessage state, IMessageHandlerContext context)
        {
            //處理超時消息
        }

        protected override void ConfigureHowToFindSaga(SagaPropertyMapper<State> mapper)
        {
            mapper.ConfigureMapping<StartOrder>(message=>message.OrderId).ToSaga(saga=>saga.OrderId);
            mapper.ConfigureMapping<CompleteOrder>(message=>message.OrderId).ToSaga(saga=>saga.OrderId);
        }
    }

//從Timeout的源碼看，這個方法是通過設置SendOptions，然後再把當前這個消息發送給自己來實現 
protected Task RequestTimeout<TTimeoutMessageType>(IMessageHandlerContext context, TimeSpan within, TTimeoutMessageType timeoutMessage)
 {
     VerifySagaCanHandleTimeout(timeoutMessage);
     var sendOptions = new SendOptions();
     sendOptions.DelayDeliveryWith(within);
     sendOptions.RouteToThisEndpoint();
     SetTimeoutHeaders(sendOptions);

     return context.Send(timeoutMessage, sendOptions);
 }

總結

       NServiceBus因為是商業產品，對分佈式消息系統所涉及到的東西都做了實現，包括分佈式事務（Outbox）、DTC都有，還有心跳檢測，監控都有，全而大，目前我們用到的也只是NServiceBus里很小的一部分功能。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!

※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!

※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!

引言

又是一年寒冬季，只身前往沿海工作，也是我第一次感受到沿海城市冬天的寒冷。剛過完金九銀十，經過一場慘烈的江湖廝殺后，相信有很多小夥伴兒已經找到了自己心儀的工作，也有的正在找工作的途中。考慮到年後必定又是一場不可避免的廝殺，這裏提前記錄一下自己平時遇到和總結的一些知識點，自己鞏固複習加強基礎的同時也希望能在你的江湖路上對你有所幫助。筆者在入職最近這家公司之前也曾有過長達3個月的閉關修鍊期，期間查閱資料無數，閱讀過很多文章，但總結下來真正讓你印象深刻的，不是那些前沿充滿神秘感的新技術，也不是為了提升代碼逼格的奇淫巧技，而是那些我們經常由於項目周期緊而容易忽略的基礎知識。所謂萬丈高樓平地起，只有你的地基打得足夠牢固，你才有搭建萬丈高樓的底氣，你才能在你的前端人生路上越走越遠。

這篇主要是先總結一下CSS相關的知識點，可能某些部分不會涉及到太多具體的細節，主要是對知識點做一下匯總，如果有興趣或者有疑惑的話可以自行百度查閱下相關資料或者在下方評論區留言討論，後續文章再繼續總結JS和其他方面相關的知識點，如有不對的地方還請指出。

1. CSS盒模型

CSS盒模型就是在網頁設計中經常用到的CSS技術所使用的一種思維模型。CSS 假定所有的HTML 文檔元素都生成了一個描述該元素在HTML文檔布局中所佔空間的矩形元素框，可以形象地將其看作是一個盒子。CSS 圍繞這些盒子產生了一種“盒子模型”概念，通過定義一系列與盒子相關的屬性，可以極大地豐富和促進各個盒子乃至整個HTML文檔的表現效果和布局結構。

CSS盒模型可以看成是由從內到外的四個部分構成，即內容區（content）、內邊距(padding)、邊框(border)和外邊距(margin)。內容區是盒子模型的中心，呈現盒子的主要信息內容；內邊距是內容區和邊框之間的空間；邊框是環繞內容區和內邊距的邊界；外邊距位於盒子的最外圍，是添加在邊框外周圍的空間。

根據計算寬高的區域我們可以將其分為IE盒模型和W3C標準盒模型，可以通過box-sizing來進行設置：

• content-box：W3C標準盒模型
• border-box：IE盒模型

區別：
W3C標準盒模型：width(寬度) = content(內容寬度)
IE盒模型：width(寬度) = content(內容寬度) + padding(內邊距) + border(邊框)

2. BFC

BFC即Block Fromatting Context(塊級格式化上下文)，它是頁面中的一塊獨立的渲染區域，並且有一套渲染規則，它決定了其子元素將如何定位，以及和其他元素的關係和相互作用。具有BFC特性的元素可以看成是一個隔離的獨立容器，讓處於BFC內部的元素與外部的元素相互隔離，使內外元素的定位不會相互影響。

IE瀏覽器下為hasLayout，一般可以通過zoom:(除normal外任意值)來觸發，hasLayout是IE瀏覽器渲染引擎的一個內部組成部分。在IE瀏覽器中，一個元素要麼自己對自身的內容進行計算大小和組織，要麼依賴於父元素來計算尺寸和和組織內容。為了調節這兩個不同的概念，渲染引擎採用了hasLayout的屬性，屬性值可以為true或false。當一個元素的hasLayout屬性為true時，我們就說這個元素有一個布局(Layout)。當擁有布局后，它會負責對自己和可能的子孫元素進行尺寸計算和定位，而不是依賴於祖先元素來完成這些工作。

2.1 觸發條件

• 根元素(<html>)
• 浮動元素(元素的float不是none)
• 絕對定位元素(元素的position為absolute或fixed)
• 行內塊元素(元素的display為inline-block)
• 表格單元格(元素的display為table-cell，HTML表格單元格默認為該值)
• 表格標題(元素的display為table-caption，HTML表格標題默認為該值)
• display值為flow-root的元素
• overflow屬性的值不為visible
• 彈性元素(display為flex或inline-flex元素的直接子元素)

• 網格元素(display為grid或者inline-grid元素的直接子元素)

  2.2 布局規則

  普通文檔流布局規則：

• 浮動的元素是不會被父級計算高度的
• 非浮動元素會覆蓋浮動元素的位置
• margin會傳遞給父級

• 兩個相鄰元素上下margin會發生重疊

BFC布局規則：

• 浮動的元素會被父級計算高度(父級觸發了BFC)
• 非浮動元素不會覆蓋浮動元素的位置(非浮動元素觸發了BFC)
• margin不會傳遞給父級(父級觸發了BFC)

• 兩個相鄰元素上下margin不會發生重疊(給其中一個元素增加一個父級，並讓它的父級觸發BFC)

  2.3 應用

• 防止margin重疊
• 清除內部浮動(原理是父級計算高度時，浮動的子元素也會參与計算)
• 自適應兩欄布局

• 防止元素被浮動元素所覆蓋

  3. 層疊上下文

  層疊上下文(stacking context)，是HTML中一個三維的概念。在CSS2.1規範中，每個盒模型的位置都是三維的，分別是平面畫布上的X軸，Y軸以及表示層疊的Z軸。一般情況下，元素在頁面上沿X軸Y軸平鋪，我們察覺不到它們在Z軸上的層疊關係。而一旦元素髮生堆疊，這時就能發現某個元素可能覆蓋了另一個元素或者被另一個元素覆蓋。

如果一個元素含有層疊上下文，我們就可以理解為這個元素在Z軸上就”高人一等”，最終表現就是它離屏幕觀察者更近。

你可以把層疊上下文理解為該元素當了官，而其他非層疊上下文元素則可以理解為普通群眾。凡是”當了官的元素”就比普通元素等級要高，也就是說元素在Z軸上更靠上，更靠近觀察者。

3.1 觸發條件

• 根層疊上下文(<html>)
• position屬性為非static值並設置z-index為具體數值
• CSS3中的屬性也可以產生層疊上下文
  • flex
  • transform
  • opacity
  • filter
  • will-change

  • -webkit-overflow-scrolling

    3.2 層疊等級

    層疊等級(stacking level)，又叫”層疊級別”或者”層疊水平”。

• 在同一個層疊上下文中，它描述定義的是該層疊上下文中的層疊上下文元素在Z軸上的上下順序

• 在其他普通元素中，它描述定義的是這些普通元素在Z軸上的上下順序

  注意：

  1. 普通元素的層疊等級優先由其所在的層疊上下文決定。
  2. 層疊等級的比較只有在當前層疊上下文元素中才有意義，不同層疊上下文中比較層疊等級是沒有意義的。

根據以上的層疊等級圖，我們在比較層疊等級時可以按照以下的思路來順序比較：

• 首先判定兩個要比較的元素是否處於同一個層疊上下文中
• 如果處於同一個層疊上下文中，則誰的層疊等級大，誰最靠上
• 如果處於不同的層疊上下文中，則先比較他們所處的層疊上下文的層疊等級
• 當兩個元素層疊等級相同，層疊順序相同時，在DOM結構中後面的元素層疊等級在前面元素之上

4. CSS3中新增的選擇器以及屬性

• 屬性選擇器：

屬性選擇器	含義描述
E[attr^=”val”]	屬性attr的值以”val”開頭的元素
E[attr$=”val”]	屬性attr的值以”val”結尾的元素
E[attr*=”val”]	屬性attr的值包含“val”子字符串的元素

• 結構偽類選擇器

選擇器	含義描述
E:root	匹配元素所在文檔的根元素，對於HTML文檔，根元素始終是<html>
E:nth-child(n)	匹配其父元素的第n個子元素，第一個編號為1
E:nth-last-child(n)	匹配其父元素的倒數第n個子元素，第一個編號為1
E:nth-of-type(n)	與:nth-child()作用類似，但是僅匹配使用同種標籤的元素
E:nth-last-of-type(n)	與:nth-last-child() 作用類似，但是僅匹配使用同種標籤的元素
E:last-child	匹配父元素的最後一個子元素，等同於:nth-last-child(1)
E:first-of-type	匹配父元素下使用同種標籤的第一個子元素，等同於:nth-of-type(1)
E:last-of-type	匹配父元素下使用同種標籤的最後一個子元素，等同於:nth-last-of-type(1)
E:only-child	匹配父元素下僅有的一個子元素，等同於:first-child:last-child或 :nth-child(1):nth-last-child(1)
E:only-of-type	匹配父元素下使用同種標籤的唯一一個子元素，等同於:first-of-type:last-of-type或 :nth-of-type(1):nth-last-of-type(1)
E:empty	匹配一個不包含任何子元素的元素，文本節點也被看作子元素
E:not(selector)	匹配不符合當前選擇器的任何元素

• CSS3新增屬性

屬性	含義描述
transition	過渡效果
transform	變換效果(移動(translate)、縮放(scale)、旋轉(rotate)、傾斜(skew))
transform-origin	設置旋轉元素的基點位置
animation	動畫效果
border-color	為邊框設置多種顏色
border-radius	圓角邊框
box-shadow	邊框陰影
border-image	邊框圖片
background-size	規定背景圖片的尺寸
background-origin	規定背景圖片的定位區域
background-clip	規定背景圖片從什麼位置開始裁切
text-shadow	文本陰影
text-overflow	文本截斷
word-wrap	對長單詞進行拆分，並換行到下一行
opacity	不透明度
box-sizing	控制盒模型的組成模式
rgba	基於r,g,b三個顏色通道來設置顏色值，通過a來設置透明度

5. CSS3中transition和animation的屬性

1) transition(過渡動畫)

用法：transition: property duration timing-function delay
| 屬性 | 含義描述 |
| —- | —- |
| transition-property | 指定哪個CSS屬性需要應用到transition效果 |
| transition-duration | 指定transition效果的持續時間 |
| transition-timing-function | 指定transition效果的速度曲線 |
| transition-delay | 指定transition效果的延遲時間 |

2) animation(關鍵幀動畫)

用法：animation: name duration timing-function delay iteration-count direction fill-mode play-state
| 屬性 | 含義描述 |
| —- | —- |
| animation-name | 指定要綁定到選擇器的關鍵幀的名稱 |
| animation-duration | 指定動畫的持續時間 |
| animation-timing-function | 指定動畫的速度曲線 |
| animation-delay | 指定動畫的延遲時間 |
| animation-iteration-count | 指定動畫的播放次數 |
| animation-direction | 指定是否應該輪流反向播放動畫 |
| animation-fill-mode | 規定當動畫不播放時（當動畫完成時，或當動畫有一個延遲未開始播放時），要應用到元素的樣式 |
| animation-play-state | 指定動畫是否正在運行或已暫停 |

6. 清除浮動的方式以及各自的優缺點

• 額外標籤法(在最後一個浮動元素的後面新加一個標籤如<div class="clear"></div>，並在其CSS樣式中設置clear: both;)

  優點：簡單，通俗易懂，寫少量代碼，兼容性好
  缺點：額外增加無語義html元素，代碼語義化差，後期維護成本大

• 給父級設置高度

  優點：簡單，寫少量代碼，容易掌握
  缺點：不夠靈活，只適用於高度固定的布局

• 觸發父級BFC(如給父元素設置overflow:hidden，特別注意的是：在IE6中還需要觸發hasLayout，例如給父元素設置zoom:1。原理是觸發父級BFC后，父元素在計算高度時，浮動的子元素也會參与計算)

  優點：簡單，代碼簡潔
  缺點：設置overflow:hidden容易造成不會自動換行導致超出的尺寸被隱藏掉，無法显示要溢出的元素

• 使用after偽元素，常見的寫法如下：

 .clearfix::after {
    content: ".";
    display: block;
    height: 0;
    line-height: 0;
    clear: both;
    visibility:hidden;
    font-size: 0;
 }
 
 .clearfix {
    // 注意此處是為了兼容IE6和IE7瀏覽器，即觸發hasLayout
    zoom: 1;
 }

優點：符合閉合浮動思想，結構語義化正確
缺點：代碼量多，因為IE6-7下不支持after偽元素，需要額外寫zoom:1來觸發hasLayout

7. 居中布局的方式

水平居中：

• 若是行內元素，則直接給其父元素設置text-align: center即可
• 若是塊級元素，則直接給該元素設置margin: 0 auto即可
• 若子元素包含浮動元素，則給父元素設置width:fit-content並且配合margin

.parent {
    width: -webkit-fit-content;
    width: -moz-fit-content;
    width: fit-content;
    margin: 0 auto;
}

• 使用flex布局的方式，可以輕鬆實現水平居中，即使子元素中存在浮動元素也同樣適用

// flex 2012年版本寫法
.parent {
    display: flex;
    flex-direction: row;
    justify-content: center;
}

// flex 2009年版本寫法
.parent {
    display: box;
    box-orient: horizontal;
    box-pack: center;
}

• 使用絕對定位的方式，再配合CSS3新增的transform屬性

.child {
    position: absolute;
    left: 50%;
    transform: translate(-50%, 0);
}

• 使用絕對定位的方式，再配合負值的margin-left(此方法需要固定寬度)

.child {
    position: absolute;
    left: 50%;
    width: 200px; // 假定寬度為200px
    margin-left: -100px; // 負值的絕對值為寬度的一半
}

• 使用絕對定位的方式，再配合left:0;right:0;margin:0 auto;(此方法需要固定寬度)

.child {
    position: absolute;
    left: 0;
    right: 0;
    margin: 0 auto;
    width: 200px; // 假定寬度為200px
}

垂直居中：

• 若元素是單行文本，則直接給該元素設置line-height等於其父元素的高度
• 若元素是行內塊級元素，可以配合使用display:inline-block;vertical-align:middle和一個偽元素來讓內容塊居中

.parent::after, .child {
    display: inline-block;
    vertical-align: middle;
}

.parent::after {
    content: "";
    height: 100%;
}

• 使用vertical-align屬性並且配合使用display:table和display:table-cell來讓內容塊居中

.parent {
    display: table;
}

.child {
    display: table-cell;
    vertical-align: middle;
}

• 使用flex布局的方式，可以輕鬆實現垂直居中，即使子元素中存在浮動元素也同樣適用

// flex 2012年版本寫法
.parent {
    display: flex;
    align-items: center;
}

// flex 2009年版本寫法
.parent {
    display: box;
    box-orient: vertical;
    box-pack: center;
}

• 使用絕對定位的方式，再配合CSS3新增的transform屬性

.child {
    position: absolute;
    top: 50%;
    transform: translate(0, -50%);
}

• 使用絕對定位的方式，再配合負值的margin-top(此方法需要固定高度)

.child {
    position: absolute;
    top: 50%;
    height: 200px; // 假定高度為200px
    margin-top: -100px; // 負值的絕對值為高度的一半
}

• 使用絕對定位的方式，再配合top:0;bottom:0;margin:auto 0;(此方法需要固定高度)

.child {
    position: absolute;
    top: 0;
    bottom: 0;
    margin: auto 0;
    height: 200px; // 假定高度為200px
}

水平垂直居中：

• 使用flex布局的方式同樣可以輕鬆實現水平垂直居中

// flex 2012年版本寫法
.parent {
    display: flex;
    justify-content: center;
    align-items: center;
}

// flex 2009年版本寫法
.parent {
    display: box;
    box-pack: center;
    box-align: center;
}

• 使用絕對定位的方式，再配合CSS3新增的transform屬性

.child {
    position: absolute;
    left: 50%;
    top: 50%;
    transform: translate(-50%, -50%);
}

• 使用絕對定位的方式，再配合使用負值的margin-top和負值的margin-left(此方法需要同時固定寬度和高度)

.child {
    position: absolute;
    left: 50%;
    top: 50%;
    margin-top: -50px; // 負值的絕對值為高度的一半
    margin-left: -100px; // 負值的絕對值為寬度的一半
    width: 200px; // 假定寬度為200px
    height: 100px; // 假定高度為100px
}

8. CSS的優先級和權重

選擇器(優先級從高到低)	示例	特殊性值
!important(重要性標識)	div { color: #fff !important; }	無，但為了方便記憶，可將其表示為1,0,0,0,0
行內樣式	<div style="color: #fff;"></div>	1,0,0,0
id選擇器	#id	0,1,0,0
類，偽類和屬性選擇器	.content, :first-child, [type="text"]	0,0,1,0
標籤和偽元素選擇器	h1, ::after	0,0,0,1
通配符、子選擇器、相鄰選擇器	*, div > p, p + p	0,0,0,0
繼承	span { color: inherit; }	無
瀏覽器默認值	瀏覽器開發者工具右側的Styles面板中會显示user agent stylesheet字樣	無

9. 移動端1px物理像素邊框

我們知道，在移動端存在物理像素(physical pixel)和設備獨立像素(density-independent pixel)的概念。物理像素也稱為設備像素，它是显示設備中一個最微小的物理部件，每個像素可以根據操作系統設置自己的顏色和亮度。設備獨立像素也稱為密度無關像素，可以認為是計算機坐標系統中的一個點，這個點代表一個可以由程序使用的虛擬像素(比如CSS像素)，然後由相關係統轉換為物理像素。根據物理像素和設備獨立像素也衍生出了設備像素比(device pixel ratio)的概念，簡稱為dpr，其定義了物理像素和設備獨立像素的對應關係，其計算公式為設備像素比 = 物理像素 / 設備獨立像素。因為視網膜(Retina)屏幕的出現，使得一個物理像素並不能和一個設備獨立像素完全對等，如下圖所示：

在上圖中，在普通屏幕下1個CSS像素對應1個物理像素，而在Retina屏幕下，1個CSS像素卻對應4個物理像素，即在Retina屏幕下會有不同的dpr值。為了追求在移動端網頁中更好的显示質量，因此我們需要做各種各樣的適配處理，最經典的莫過於1px物理像素邊框問題，我們需要根據移動端不同的dpr值來對邊框進行處理。在JavaScript中，可以通過window.devicePixelRatio來獲取當前設備的dpr，在CSS中，可以通過-webkit-device-pixel-ratio，-webkit-min-device-pixel-ratio和-webkit-max-device-pixel-ratio來進行媒體查詢，從而針對不同的設備，來做一些樣式適配。這裏對於1px像素的邊框問題，給出一種最常見的寫法：

.border-1px {
    position: relative;
}

.border-1px::after {
    content: "";
    position: absolute;
    left: 0;
    bottom: 0;
    width: 100%;
    height: 1px;
    background-color: #000;
    -webkit-transform: scaleY(.5);
    transform: scaleY(.5);
}

@media only screen and (-webkit-min-device-pixel-ratio: 2.0), (min-device-pixel-ratio: 2.0) {
    .border-1px::after {
        -webkit-transform: scaleY(.5);
        transform: scaleY(.5);
    }
}

@media only screen and (-webkit-min-device-pixel-ratio: 3.0), (min-device-pixel-ratio: 3.0) {
    .border-1px::after {
        -webkit-transform: scaleY(.33);
        transform: scaleY(.33);
    }
}

10. 實現三欄布局的方式有哪些

三欄布局，顧名思義就是分為左中右三個模塊進行布局，並且左右兩邊固定，中間模塊根據瀏覽器的窗口變化進行自適應，效果圖如下：

這裏給出四種實現三欄布局的方式：

• 使用絕對定位的方式

.container {
    position: relative;
    height: 200px;
    line-height: 200px;
    text-align: center;
    font-size: 20px;
    color: #fff;
}

.left {
    position: absolute;
    left: 0;
    top: 0;
    width: 150px;
    background: red;
}

.main {
    margin-left: 160px;
    margin-right: 110px;
    background: green;
}

.right {
    position: absolute;
    right: 0;
    top: 0;
    width: 100px;
    background: blue;
}

<div class="container">
    <div class="left">左</div>
    <div class="main">中</div>
    <div class="right">右</div>
</div>

優點：方便快捷，簡單實用，不容易出現問題，而且還可以將<div class="main"></div>元素放到最前面，使得主要內容被優先加載。
缺點：元素脫離了文檔流，可能會造成元素的重疊。

• 使用flex布局的方式

.container {
    display: flex;      
    height: 200px;
    line-height: 200px;
    text-align: center;
    font-size: 20px;
    color: #fff;
}

.left {
    width: 150px;
    background: red;
}

.main {
    margin: 0 10px;
    flex: 1;
    background: green;
}

.right {
    width: 100px;
    background: blue;
}

<div class="container">
    <div class="left">左</div>
    <div class="main">中</div>
    <div class="right">右</div>
</div>

優點：簡單實用，是現在比較流行的方案，特別是在移動端，大多數布局都採用的這種方式，是目前比較完美的一個。
缺點：需要考慮到瀏覽器的兼容性，根據不同的瀏覽器廠商需要添加相應的前綴。

• 雙飛翼布局

.content {
    float: left;
    width: 100%;
}

.main,
.left,
.right {
    height: 200px;
    line-height: 200px;
    text-align: center;
    font-size: 20px;
    color: #fff;
}

.main {
    margin-left: 160px;
    margin-right: 110px;
    background: green;
}

.left {
    float: left;
    margin-left: -100%;
    width: 150px;
    background: red;
}

.right {
    float: right;
    margin-left: -100px;
    width: 100px;
    background: blue;
}

<div class="content">
    <div class="main">中</div>
</div>
<div class="left">左</div>
<div class="right">右</div>

優點：比較經典的一種方式，通用性強，沒有兼容性問題，而且支持主要內容優先加載。
缺點：元素脫離了文檔流，要注意清除浮動，防止高度塌陷，同時額外增加了一層DOM結構，即增加了渲染樹生成的計算量。

• 聖杯布局

.container {
    margin-left: 160px;
    margin-right: 110px;
}

.left,
.main,
.right {
    height: 200px;
    line-height: 200px;
    text-align: center;
    font-size: 20px;
    color: #fff;    
}

.main {
    float: left;
    width: 100%;
    background: green;      
}

.left {
    position: relative;
    left: -160px;
    margin-left:  -100%;
    float: left;
    width: 150px;
    background: red;
}

.right {
    position: relative;
    right: -110px;
    margin-left:  -100px;
    float: left;
    width: 100px;
    background: blue;
}

<div class="container">
    <div class="main">中</div>
    <div class="left">左</div>
    <div class="right">右</div>
</div>

優點：相比於雙飛翼布局，結構更加簡單，沒有多餘的DOM結構層，同樣支持主要內容優先加載。
缺點：元素同樣脫離了文檔流，要注意清除浮動，防止高度塌陷。

11. 實現等高布局的方式有哪些

等高布局，顧名思義就是在同一個父容器中，子元素高度相等的布局。從等高布局的實現方式來說，可以分為兩種，分別是偽等高和真等高。偽等高是指子元素的高度差依然存在，只是視覺上給人的感覺就是等高，真等高是指子元素的高度真實相等。效果圖如下：

這裏給出五種實現等高布局的方式：

偽等高：

• 使用padding-bottom和負的margin-bottom來實現

.container {
    position: relative;
    overflow: hidden;
}
    
.left,
.main,
.right {
    padding-bottom: 100%;
    margin-bottom: -100%;
    float: left;
    color: #fff;
}

.left {
    width: 20%;
    background: red;
}

.main {
    width: 60%;
    background: green;
}

.right {
    width: 20%;
    background: blue;
}

<div class="container">
    <div class="left">左側內容</div>
    <div class="main">
        <p>中間內容</p>
        <p>中間內容</p>
        <p>中間內容</p>
    </div>
    <div class="right">右側內容</div>
</div>

真等高：

• 使用flex布局的方式

.container {
    display: flex;
}

.left,
.main,
.right {
    flex: 1;
    color: #fff;
}

.left {
    background: red;
}

.main {
    background: green;
}

.right {
    background: blue;
}

<div class="container">
    <div class="left">左側內容</div>
    <div class="main">
        <p>中間內容</p>
        <p>中間內容</p>
        <p>中間內容</p>
    </div>
    <div class="right">右側內容</div>
</div>

• 使用絕對定位的方式

.container {
  position: relative;
  height: 200px;
}

.left,
.main,
.right {
    position: absolute;
    top: 0;
    bottom: 0;
    color: #fff;
}

.left {
    left: 0;
    width: 20%;
    background: red;
}

.main {
    left: 20%;
    right: 20%;
    background: green;
}

.right {
    right: 0;
    width: 20%;
    background: blue;
}

<div class="container">
    <div class="left">左側內容</div>
    <div class="main">
        <p>中間內容</p>
        <p>中間內容</p>
        <p>中間內容</p>
    </div>
    <div class="right">右側內容</div>
</div>

• 使用table布局的方式

.container {
    width: 100%;
    display: table;
}

.left,
.main,
.right {
    display: table-cell;
    color: #fff;
}

.left {
    width: 20%;
    background: red;
}

.main {
    width: 60%;
    background: green;
}

.right {
    width: 20%;
    background: blue;
}

<div class="container">
    <div class="left">左側內容</div>
    <div class="main">
        <p>中間內容</p>
        <p>中間內容</p>
        <p>中間內容</p>
    </div>
    <div class="right">右側內容</div>
</div>

• 使用grid網格布局的方式

.container {
    display: grid;
    width: 100%;
    grid-template-columns: 1fr 1fr 1fr;
    color: #fff;
}

.left {
    background: red;
}

.main {
    background: green;
}

.right {
    background: blue;
}

<div class="container">
    <div class="left">左側內容</div>
    <div class="main">
        <p>中間內容</p>
        <p>中間內容</p>
        <p>中間內容</p>
    </div>
    <div class="right">右側內容</div>
</div>

12. CSS實現三角形的原理

工作中我們經常會遇到需要三角形圖標的應用場景，例如內容展開收起、左右箭頭點擊切換輪播，點擊某條列表數據查看詳情等。三角形圖標的應用範圍之廣，使得我們有必要了解一下它的實現原理。
1) 首先我們來實現一個最基礎的邊框效果

.content {
    width: 50px;
    height: 50px;
    border: 2px solid;
    border-color:#ff9600 #3366ff #12ad2a #f0eb7a;
}

效果如下：

2) 然後我們嘗試將border值放大10倍

.content {
    width: 50px;
    height: 50px;
    border: 20px solid;
    border-color: #ff9600 #3366ff #12ad2a #f0eb7a;
}

效果如下：

上圖中我們可以很清楚地看到，在繪製border的時候並不是矩形區域，而是梯形區域，那麼此時如果我們將width和height值設置為0，看會發生什麼：

.content {
    width: 0;
    height: 0;
    border: 20px solid;
    border-color: #ff9600 #3366ff #12ad2a #f0eb7a;
}

效果如下：

此時會看到一個由四個三角形拼裝而成的矩形區域，即由上下左右四個邊框組合而成。因此不難想象，如果我們想得到某一個方向的三角形，我們只需要讓其他方向的邊框不可見就行了，例如我們想得到一個朝左的三角形：

.content {
    width: 0;
    height: 0;
    border: 20px solid;
    border-color: transparent #3366ff transparent transparent;
}

效果如下:

這樣就得到了一個很完美的三角形圖標，是不是很簡單？

13. link與@import的區別

• 從屬關係區別

  @import是CSS提供的語法規則，只有導入樣式表的作用；link是HTML提供的標籤，不僅可以加載 CSS 文件，還可以定義 RSS，Rel連接屬性，設置瀏覽器資源提示符preload、prefetch等。

• 加載順序區別

  HTML文檔在解析的過程當中，如果遇到link標籤，則會立即發起獲取CSS文件資源的請求；@import引入的CSS將在頁面加載完畢后才會被加載。

• 兼容性區別

  @import是CSS2.1才有的語法，因此需要IE5以上才能識別；link標籤作為HTML元素，不存在兼容性問題。

• DOM可控性區別

  link標籤可以通過JS來動態引入，而@import無法通過JS來插入樣式

const loadStyle = (url) => {
    const link = document.createElement('link');
    link.setAttribute('type', 'text/css');
    link.setAttribute('rel', 'stylesheet');
    link.setAttribute('href', url);
    
    document.head.appendChild(link);
}

14. 瀏覽器是怎樣解析CSS選擇器的

CSS選擇器的解析是從右向左解析的。若從左向右地匹配，發現不符合規則，需要進行回溯，會損失很多性能。若從右向左匹配，先找到所有的最右節點，對於每一個節點，向上尋找其父節點直到找到根元素或滿足條件的匹配規則，則結束這個分支的遍歷。兩種匹配規則的性能差別很大，是因為從右向左的匹配在第一步就篩選掉了大量的不符合條件的最右節點(恭弘=叶 恭弘子節點)，而從左向右的匹配規則的性能都浪費在了失敗的查找上面。而在CSS解析完畢后，需要將解析的結果與DOM Tree的內容一起進行分析建立一棵 Render Tree，最終用來進行繪圖。在建立Render Tree時瀏覽器就要為每個DOM Tree中的元素根據CSS的解析結果(Style Rules)來確定生成怎樣的Render Tree。

15. CSS的性能優化方案

• 層級盡量扁平，避免嵌套過多層級的選擇器；
• 使用特定的選擇器，避免解析器過多層級的查找；
• 減少使用通配符與屬性選擇器；
• 減少不必要的多餘屬性；
• 避免使用!important標識，可以選擇其他選擇器；
• 實現動畫時優先使用CSS3的動畫屬性，動畫時脫離文檔流，開啟硬件加速；
• 使用link標籤代替@import；
• 將渲染首屏內容所需的關鍵CSS內聯到HTML中；
• 使用資源預加載指令preload讓瀏覽器提前加載CSS資源並緩存；
• 使用Gulp，Webpack等構建工具對CSS文件進行壓縮處理；

推薦閱讀

交流

終於接近尾聲了，居然花費掉了我一整個周末的時間，不過這篇主要是先總結一下CSS相關的知識點，當然還有很多地方沒有總結到，只是列出了個人覺得比較容易考察的點，如果你有其他補充的，歡迎在下方留言區討論哦，也歡迎關注我的公眾號[前端之境]，關注后我可以拉你加入微信前端交流群，我們一起互相交流學習，共同進步。
後續會陸續總結出JS方面、瀏覽器視角、算法基礎和框架方面的內容，希望你能夠喜歡！

文章已同步更新至，若覺文章尚可，歡迎前往star！

你的一個點贊，值得讓我付出更多的努力！

逆境中成長，只有不斷地學習，才能成為更好的自己，與君共勉！

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

前言

這一篇來源我的公眾號，如果你沒看過，正好直接看看，如果看過了也可以再看看，我稍微修改了一些內容，今天講解的內容如下：

 

 

 

 

 

 

 

一、什麼是單例模式

 

【單例模式】，英文名稱：Singleton Pattern，這個模式很簡單，一個類型只需要一個實例，他是屬於創建類型的一種常用的軟件設計模式。通過單例模式的方法創建的類在當前進程中只有一個實例（根據需要，也有可能一個線程中屬於單例，如：僅線程上下文內使用同一個實例）。

1、單例類只能有一個實例。

2、單例類必須自己創建自己的唯一實例。

3、單例類必須給所有其他對象提供這一實例。

 

那咱們大概知道了，其實說白了，就是我們整個項目周期內，只會有一個實例，當項目停止的時候，實例銷毀，當重新啟動的時候，我們的實例又會產品。

上文中說到了一個名詞【創建類型】的設計模式，那什麼是創建類型的設計模式呢？

創建型（Creational）模式：負責對象創建，我們使用這個模式，就是為了創建我們需要的對象實例的。

 

那除了創建型還有其他兩種類型的模式：

結構型（Structural）模式：處理類與對象間的組合

行為型（Behavioral）模式：類與對象交互中的職責分

這兩種設計模式，以後會慢慢說到，這裏先按下不表。

咱們就重點從0開始分析分析如何創建一個單例模式的對象實例。

 

二、如何創建單例模式

 

實現單例模式有很多方法：從“懶漢式”到“餓漢式”，最後“雙檢鎖”模式，這裏咱們就慢慢的，從一步一步的開始講解如何創建單例。

 

1、正常的思考邏輯順序

 

既然要創建單一的實例，那我們首先需要學會如何去創建一個實例，這個很簡單，相信每個人都會創建實例，就比如說這樣的：

/// <summary>
/// 定義一個天氣類
/// </summary>
public class WeatherForecast
{
    public WeatherForecast()
    {
        Date = DateTime.Now;
    }
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}


 [HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     WeatherForecast weather = new WeatherForecast();
     return weather;
 }

 

我們每次訪問的時候，時間都是會變化，所以我們的實例也是一直在創建，在變化：

 

 

相信每個人都能看到這個代碼是什麼意思，不多說，直接往下走，我們知道，單例模式的核心目的就是：

必須保證這個實例在整個系統的運行周期內是唯一的，這樣可以保證中間不會出現問題。

 

那好，我們改進改進，不是說要唯一一個么，好說！我直接返回不就行了：

 

 /// <summary>
 /// 定義一個天氣類
 /// </summary>
 public class WeatherForecast
 {
     // 定義一個靜態變量來保存類的唯一實例
     private static WeatherForecast uniqueInstance;

     // 定義私有構造函數，使外界不能創建該類實例
     private WeatherForecast()
     {
         Date = DateTime.Now;
     }
     /// <summary>
     /// 靜態方法，來返回唯一實例
     /// 如果存在，則返回
     /// </summary>
     /// <returns></returns>
     public static WeatherForecast GetInstance()
     {
         // 如果類的實例不存在則創建，否則直接返回
         // 其實嚴格意義上來說，這個不屬於【單例】
         if (uniqueInstance == null)
         {
             uniqueInstance = new WeatherForecast();
         }
         return uniqueInstance;
     }
     public DateTime Date { get; set; }public int TemperatureC { get; set; }
     public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
     public string Summary { get; set; }
 }

 

 

然後我們修改一下調用方法，因為我們的默認構造函數已經私有化了，不允許再創建實例了，所以我們直接這麼調用：

[HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     WeatherForecast weather = WeatherForecast.GetInstance();
     return weather;
 }

 

最後來看看效果：

 

 

這個時候，我們可以看到，時間已經不發生變化了，也就是說我們的實例是唯一的了，大功告成！是不是很開心！

 

但是，別著急，問題來了，我們目前是單線程的，所以只有一個，那如果多線程呢，如果多個線程同時訪問，會不會也會正常呢？

這裏我們做一個測試，我們在項目啟動的時候，用多線程去調用：

 

 [HttpGet]
 public WeatherForecast Get()
 {
     // 實例化一個對象實例
     //WeatherForecast weather = WeatherForecast.GetInstance();

     // 多線程去調用
     for (int i = 0; i < 3; i++)
     {
         var th = new Thread(
         new ParameterizedThreadStart((state) =>
         {
             WeatherForecast.GetInstance();
         })
         );
         th.Start(i);
     }
     return null;
 }

 

然後我們看看效果是怎樣的，按照我們的思路，應該是只會走一遍構造函數，其實不是：

 

 

 

 

 

 

3個線程在第一次訪問GetInstance方法時，同時判斷(uniqueInstance ==null)這個條件時都返回真，然後都去創建了實例，這個肯定是不對的。那怎麼辦呢，只要讓GetInstance方法只運行一個線程運行就好了，我們可以加一個鎖來控制他，代碼如下：

public class WeatherForecast
{
    // 定義一個靜態變量來保存類的唯一實例
    private static WeatherForecast uniqueInstance;
    // 定義一個鎖，防止多線程
    private static readonly object locker = new object();

    // 定義私有構造函數，使外界不能創建該類實例
    private WeatherForecast()
    {
        Date = DateTime.Now;
    }
    /// <summary>
    /// 靜態方法，來返回唯一實例
    /// 如果存在，則返回
    /// </summary>
    /// <returns></returns>
    public static WeatherForecast GetInstance()
    {
        // 當第一個線程執行的時候，會對locker對象 "加鎖"，
        // 當其他線程執行的時候，會等待 locker 執行完解鎖
        lock (locker)
        {
            // 如果類的實例不存在則創建，否則直接返回
            if (uniqueInstance == null)
            {
                uniqueInstance = new WeatherForecast();
            }
        }

        return uniqueInstance;
    }
    public DateTime Date { get; set; }

    public int TemperatureC { get; set; }

    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);

    public string Summary { get; set; }
}

 

這個時候，我們再併發測試，發現已經都一樣了，這樣就達到了我們想要的效果，但是這樣真的是最完美的么，其實不是的，因為我們加鎖，只是第一次判斷是否為空，如果創建好了以後，以後就不用去管這個 lock 鎖了，我們只關心的是 uniqueInstance 是否為空，那我們再完善一下：

 

/// <summary>
/// 定義一個天氣類
/// </summary>
public class WeatherForecast
{
    // 定義一個靜態變量來保存類的唯一實例
    private static WeatherForecast uniqueInstance;
    // 定義一個鎖，防止多線程
    private static readonly object locker = new object();

    // 定義私有構造函數，使外界不能創建該類實例
    private WeatherForecast()
    {
        Date = DateTime.Now;
    }
    /// <summary>
    /// 靜態方法，來返回唯一實例
    /// 如果存在，則返回
    /// </summary>
    /// <returns></returns>
    public static WeatherForecast GetInstance()
    {
        // 當第一個線程執行的時候，會對locker對象 "加鎖"，
        // 當其他線程執行的時候，會等待 locker 執行完解鎖
        if (uniqueInstance == null)
        {
            lock (locker)
            {
                // 如果類的實例不存在則創建，否則直接返回
                if (uniqueInstance == null)
                {
                    uniqueInstance = new WeatherForecast();
                }
            }
        }

        return uniqueInstance;
    }
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}

 

這樣才最終的完美實現我們的單例模式！搞定。

 

2、幽靈事件：指令重排

當然，如果你看完了上邊的那四步已經可以出師了，平時我們就是這麼使用的，也是這麼想的，但是真的就是萬無一失么，有一個 JAVA 的朋友提出了這個問題，C# 中我沒有聽說過，是我孤陋寡聞了么：

單例模式的幽靈事件，時令重排會偶爾導致單例模式失效。

 

是不是聽起來感覺很高大上，而不知所云，沒關係，咱們平時用不到，但是可以了解了解：

為何要指令重排？       

指令重排是指的 volatile，現在的CPU一般採用流水線來執行指令。一個指令的執行被分成：取指、譯碼、訪存、執行、寫回、等若干個階段。然後，多條指令可以同時存在於流水線中，同時被執行。
指令流水線並不是串行的，並不會因為一個耗時很長的指令在“執行”階段呆很長時間，而導致後續的指令都卡在“執行”之前的階段上。
相反，流水線是并行的，多個指令可以同時處於同一個階段，只要CPU內部相應的處理部件未被佔滿即可。比如說CPU有一個加法器和一個除法器，那麼一條加法指令和一條除法指令就可能同時處於“執行”階段, 而兩條加法指令在“執行”階段就只能串行工作。
相比於串行+阻塞的方式，流水線像這樣并行的工作，效率是非常高的。

然而，這樣一來，亂序可能就產生了。比如一條加法指令原本出現在一條除法指令的後面，但是由於除法的執行時間很長，在它執行完之前，加法可能先執行完了。再比如兩條訪存指令，可能由於第二條指令命中了cache而導致它先於第一條指令完成。
一般情況下，指令亂序並不是CPU在執行指令之前刻意去調整順序。CPU總是順序的去內存裏面取指令，然後將其順序的放入指令流水線。但是指令執行時的各種條件，指令與指令之間的相互影響，可能導致順序放入流水線的指令，最終亂序執行完成。這就是所謂的“順序流入，亂序流出”。

 

這個是從網上摘錄的，大概意思看看就行,理解雙檢鎖失效原因有兩個重點

1、編譯器的寫操作重排問題.
例 : B b = new B();

上面這一句並不是原子性的操作,一部分是new一個B對象,一部分是將new出來的對象賦值給b.

直覺來說我們可能認為是先構造對象再賦值.但是很遺憾,這個順序並不是固定的.再編譯器的重排作用下,可能會出現先賦值再構造對象的情況.

2、結合上下文,結合使用情景.

理解了1中的寫操作重排以後,我卡住了一下.因為我真不知道這種重排到底會帶來什麼影響.實際上是因為我看代碼看的不夠仔細,沒有意識到使用場景.雙檢鎖的一種常見使用場景就是在單例模式下初始化一個單例並返回,然後調用初始化方法的方法體內使用初始化完成的單例對象.

 

三、Singleton = 單例 ？

 上邊我們說了很多，也介紹了很多單例的原理和步驟，那這裏問題來了，我們在學習依賴注入的時候，用到的 Singleton 的單例注入，是不是和上邊說的一回事兒呢，這裏咱們直接多多線程測試一下就行：

 

/// <summary>
/// 定義一個心情類
/// </summary>
public class Feeling
{
    public Feeling()
    {
        Date = DateTime.Now;
    }
    public DateTime Date { get; set; }
}


 // 單例注入
 services.AddSingleton<Feeling>();


[HttpGet]
public WeatherForecast Get()
{

    // 多線程去調用
    for (int i = 0; i < 3; i++)
    {
        var th = new Thread(
        new ParameterizedThreadStart((state) =>
        {
            //WeatherForecast.GetInstance();
            
            // 此刻的心情
            Feeling feeling = new Feeling();
            Console.WriteLine(feeling.Date);
        })
        );
        th.Start(i);
    }
    return null;
}

 

測試的結果，情理之中，也是意料之外：

 

 

竟然和我們上邊說的是一樣的， 
Singleton是一種懶漢模式 的單例， 因為結論可以看出，有時候我們使用單例模式，並不是寫一個 Sigleton 就能滿足的。    

四、單例模式的優缺點

 

        【優】、單例模式的優點：

             （1）、保證唯一性：防止其他對象實例化，保證實例的唯一性；

             （2）、全局性：定義好數據后，可以再整個項目種的任何地方使用當前實例，以及數據；

        【劣】、單例模式的缺點： 

             （1）、內存常駐：因為單例的生命周期最長，存在整個開發系統內，如果一直添加數據，或者是常駐的話，會造成一定的內存消耗。

 

以下內容來自百度百科：

優點

一、實例控制 單例模式會阻止其他對象實例化其自己的單例對象的副本，從而確保所有對象都訪問唯一實例。
二、靈活性 因為類控制了實例化過程，所以類可以靈活更改實例化過程。  

缺點

一、開銷 雖然數量很少，但如果每次對象請求引用時都要檢查是否存在類的實例，將仍然需要一些開銷。可以通過使用靜態初始化解決此問題。
二、可能的開發混淆 使用單例對象（尤其在類庫中定義的對象）時，開發人員必須記住自己不能使用
new關鍵字實例化對象。因為可能無法訪問庫源代碼，因此應用程序開發人員可能會意外發現自己無法直接實例化此類。
三、對象生存期 不能解決刪除單個對象的問題。在提供內存管理的語言中（例如基於.NET Framework的語言），只有單例類能夠導致實例被取消分配，因為它包含對該實例的私有引用。在某些語言中（如 C++），其他類可以刪除對象實例，但這樣會導致單例類中出現懸浮引用。

 

五、示例代碼

 

 

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象

.NET Core love gRPC

千呼萬喚的 .NET Core 3.0 終於在 9 月份正式發布，在它的眾多新特性中，除了性能得到了大大提高，比較受關注的應該是 ASP.NET Core 3.0 對 gRPC 的集成了。
它的源碼託管在 grpc-dotnet 這個 Github 庫中，由微軟 .NET 團隊與谷歌 gRPC 團隊共同維護.

.NET Core 對 gRPC 的支持在 grpc 官方倉庫早已有實現（grpc/csharp），但服務端沒有很好地與 ASP.NET Core 集成，使用起來還需要自己進行一些集成擴展。
而 ASP.NET Core 3.0 新增了 gRPC 服務的託管功能，能讓 gRPC 與 ASP.NET Core 框架本身的特性很好地結合，如日誌、依賴注入、身份認證和授權，並由 Kestrel 服務器提供 HTTP/2 鏈接，性能上得到充分保障。

推薦把項目中已有的 RPC 框架或者內部服務間 REST 調用都遷移到 gRPC 上，因為它已經是雲原生應用的標準 RPC 框架，在整個 CNCF 主導下的雲原生應用開發生態里 gRpc 有着舉足輕重的地位。

對於 gRPC 的使用方式，前段時間已經有其他大神寫的幾篇文章了，這裏就不再贅述了。
本文主要介紹的是區別於標準使用規範的，但對.NET 應用更加友好的使用方式，最後會提供源碼來展示。

作為對比，還是要列一下標準的使用步驟：

1. 定義 proto 文件，包含服務、方法、消息對象的定義
2. 引入 Grpc.Tools Nuget 包並添加指定 proto 路徑和生成模式
3. 生成項目，得到服務端的抽象類或客戶端的調用客戶端組件
4. 實現服務端抽象類，並在 ASP.NET Core 註冊這個服務的路由端點
5. DI 註冊 gRPC 服務。
6. 客戶端用 Grpc.Net.ClientFactory Nuget 包進行統一配置和依賴注入

.NET Core 對 gRPC 的大力支持使開發者開發效率大大提高，入門難度也減少了許多，完全可以成為跟 WebApi 等一樣的 .NET Core 技術棧的標配。

proto 在單一語言系統架構中的局限性

使用 proto 文件的好處是多語言支持，同一份 proto 可以生成各種語言的服務和客戶端，可以讓用不同語言開發的微服務直接互相遠程調用。但 proto 文件作為不同服務間的契約，不可以經常修改，否則就會對使用了它的服務造成不同程度的影響，因此對 proto 文件的版本控制需要得到重視。

另外，我們的應用程序還不應該與 gRPC 耦合，否則就會導致系統架構被這些實現細節所綁架。直接依賴 proto 文件和由它生成的代碼，就是對 gRPC 的強耦合。

例如，當應用程序在演進的過程中，複雜度還未達到完全部署隔離的必要時，為了避免因“完全邊界”引入的部署運維複雜性，又能預留隔離的可能性，需要有一層接口層作為“不完全邊界”。

又比如，目前在 windows 系統的 iis 上還不支持 grpc-dotnet，當有 windows 上的應用程序需要使用 RPC，就需要換成 REST 的實現了。

因此，為了不讓應用程序對 gRPC 過於依賴，還應該使用一層抽象（接口）層與其解耦，用接口來隔離對 RPC 實現的依賴，這樣在需要使用不同的實現時，可以通過註冊不同的實現來方便地切換。

在這些場景下，本文要介紹的 Code-First gRPC 使用方法就發揮作用了。

Code-First gRPC

說了這麼久，我好像還沒正式介紹 Code-First gRPC，到底他有多適合在單一語言系統架構中實現 gRPC 呢？下面要介紹的就是基於大名鼎鼎的 protobuf-net 實現的 gRPC 框架，protobuf-net.Grpc。

protobuf-net 是在過去十幾年前到現在一直在 .NET 中有名的 Protobuf 庫，想用 Protobuf 序列化時就會用到這個庫。他的特性就是可以把 C# 代碼編寫的類能以 Protobuf 的協議進行序列化和反序列化，而不是 proto 文件再生成這些類。而 protobuf-net.Grpc 則是一脈相承，可以把 C# 寫的接口，在服務端方便地把接口的實現類註冊成 ASP.NET Core 的 gRPC 服務，在客戶端把接口動態代理實現為調用客戶端，調用前面的這個服務端。

用法很簡單，只要聲明一個接口為您的服務契約：

[ServiceContract]
public interface IMyAmazingService {
    ValueTask<SearchResponse> SearchAsync(SearchRequest request);
    // ...
}

然後實現該接口的服務端：

public class MyServer : IMyAmazingService {
    // ...
}

或者向系統獲取客戶端：

var client = http.CreateGrpcService<IMyAmazingService>();
var results = await client.SearchAsync(request);

這相當於以下 .proto 中的服務：

service MyAmazingService {
    rpc Search (SearchRequest) returns (SearchResponse) {}
    // ...
}

protobuf-net.Grpc 同樣通過普通類型定義支持 gRPC 的四種模式，把 C# 8.0 中最新的 IAsyncEnumerable 類型識別成 proto 中的 stream，單向流、雙向流都可以實現！而且用 IAsyncEnumerable 實現可比 proto 生成的類方便很多。

例如 proto 雙向流定義：

rpc chat(stream ChatRequest) returns ( stream ChatResponse);

生成出來的方法是：

Task BathTheCat(IAsyncStreamReader<ChatRequest> requestStream, IServerStreamWriter<ChatResponse> responseStream)

而 protobuf-net.Grpc 只要定義一個方法：

IAsyncEnumerable<ChatResponse> SubscribeAsync(IAsyncEnumerable<ChatRequest> requestStream);

由此可見，protobuf-net.Grpc 無需在契約層引入第三方庫，充分運用了 C# 類型系統，把方法、類型映射到兼容了 gRPC 的服務定義上。

上文所說的 proto 局限也迎刃而解了，函數調用、gRPC、REST 都能方便切換。（REST 實現可以參考我的開源框架 shriek-fx 中的 Shriek.ServiceProxy.Http ）組件。

下一篇，我將主要介紹利用 protobuf-net.Grpc 的 gRPC 雙向流模式與 Blazor 實現一個簡單的在線即時聊天室。

相關鏈接：

• protobuf-net.Grpc：
• shriek-fx：
• GrpcChat:

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】

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

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

※自行創業 缺乏曝光? 下一步"網站設計"幫您第一時間規劃公司的門面形象