抱歉各位朋友，由於各種私事公事，本應該在 19 年底發布的 Swifter.MessagePack 庫延遲了這麼久才發布，我深感抱歉。

MsgPack 簡介

MsgPack 一種非常輕巧的二進制數據交換格式，巧妙的設計讓它相比其他二進制數據格式更可讀，並且有着不錯的壓縮率和邏輯性能，是目前相當火熱的數據交換格式。

Swifter.MessagePack 遵循 MsgPack 新的規範實現；相比 .NET 其他 MsgPack 序列化庫，Swifter.MessagePack 有着更好的性能，生成的內容更緊湊合理且更簡單易用。

Nuget：Swifter.MessagePack，Swifter.Json，Swifter.Data

GitHub：Swifter.MessagePack，Swifter.Json

如果您想使用 Swifter 庫，請在 Nuget 上安裝/下載最新版本，如需單文件版本，請自行生成/合併。

 

簡單使用 Swifter.MessagePack

MessagePackFormatter 類內部還有數十個方法重載，包括靜態和實例方法，總有一些適合您；這些方法都是線程安全的。

更多使用方法請參考早期關於 Swifter.Json 的文章，GitHub 或 Wiki；學習交流進 Swifter 的 QQ 群：133630914（新群，歡迎加入）。

 

Swifter 框架的特性

(1) Swifter 可以運行在 .NET Framework 2.0+, .NET Core 2.0+, .NET Standard 2.0+, MONO JIT, MONO AOT, Xamarin.Android, Xamarin.iOS, Unity JIT 等平台/運行時上，Unity IL2CPP 運行時由於沒有我們測試環境，不知可否正常運行，更多信息請看下面的 AOT 說明。

(2) Swifter 有着深層的抽象封裝，這雖然帶來了一些性能和內存的損耗，但也獲得了更高的擴展性；Swifter.Json/Swifter.MessagePack/Swifter.Data 的可公用的代碼非常多，這使得在 Swifter 上實現一個新的序列化庫只需要編寫少量代碼即可實現，這是其他框架難實現的。

(3) 雖然 Swifter 有很多接口和抽象編程，但是 Swifter 並沒有因此比其他的框架慢或內存佔用大，反比它們更快和更小內存佔用；這是因為 Swifter 從來都是使用更好算法和邏輯來獲取性能，而不是使用更直接的代碼獲取直接的性能。

(4) 作為類庫開發者，我們深知每個人開發和測試的側重點都與他人不一樣，自己找出自己的問題太難，所以 Swifter.Json 和 Swifter.MessagePack 除了我們自己的測試單元之外， 還 “偷” 了 Newtonsoft, Neuecc 和 Spanjson 的 5000+ 個測試單元（ 去除了 Newtonsoft 的部分測試單元）；現已測試通過 4200+ 個，不通過 800+ 個是我們認為可以允許或是更加合理的行為。（不勞而獲的測試單元確實用着很爽，但事實是我們”搬”這些測試單元用了 3 天，無腦替換改到手指抽筋）

 

Swifter.Json 和 Swifter.MessagePack

(1) Swifter.MessagePack 和 Swifter.Json 一樣，都有着非常優異的性能和極小的額外內存分配。

(2) Swifter.MessagePack 和 Swifter.Json 的 API 大致相同，如果使用者同時使用它們，那麼可以極小成本在它們之間切換。

(3) 得益於 Swifter.Core 的強大數據映射，Swifter.MessagePack 和 Swifter.Json 都同時支持 .NET 上大多數常用的數據結構和類型。

(4) Swifter.MessagePack 和 Swifter.Json 對重複引用的對象的表示方式不一樣，在開啟 MultiReferencingReference 配置項后，Swifter.Json 將使用 { “$ref”: “#/obj/1/target” } 來表示重複引用的對象，而 Swifter.MessagePack 使用對象在 MsgPack 內容的偏移量表示重複引用的對象；相比之下 Swifter.MessagePack 的方案更簡單性能更快，但是可讀性較差，不過說來 MsgPack 本來就是要專門的工具才能閱讀。

(5) Swifter.MessagePack 在序列化基礎類型時，在保證精度不丟失的前提下，將大數據類型轉換為更小數據類型，以得到更緊湊的 MsgPack 內容（如將 double 123 轉換為 int 123，int 123 只需要 1 個字節即可表示，如果不做轉換則需要 9 個字節表示）。

(6) Swifter.MessagePack 在序列化未知長度的集合時（如 Enumerable<T>），會將長度定義為四字節 (FixArray32)，然後在寫入完成后把實際長度賦予這四字節長度；這樣雖然在較短的未知長度集合時，將產生 1-3 個 0；但是這避免了將未知長度的集合轉換為 List<T> 或 T[], 這提高了性能也減少了內存分配，這是不虧的（因為未知長度的集合很常用，如 Linq，DbDataReader 等）。

 

新版本做了啥？

(1) 主要是解決了已知 BUG，包括了 Issues 上提到的幾個。

(2) 允許將 “” 值解析為 DateTime, int?, double 等基礎類型的默認值，但是需要啟用 EmptyStringAsDefault 配置項，默認未開啟。

(3) 解決了 Swifter.Json 浮點數: float, double 失真的問題，並增加了 UseSystemFloatingPointsMethods 配置項使用系統的浮點數方法，此配置項的更多說明請看該配置項的註釋。

(4) 增加了序列化的事件：ObjectFiltering 和 ArrayFiltering，這兩個事件可以對正在序列化中的 鍵/值 做處理和篩選，包括駝峰命名法，忽略一些值等。它們被放在 JsonFormatter 和 MessagePackFormatter 的實例裏面。

(5) 增加了 .NET 對象的持久序列化和反序列化功能，這個功能將對象序列化為包含類型信息和字段值的內容，不包含邏輯信息；使用 SerializationBox<T> 盒子使用此功能。圖示：

更多新增的功能請繼續看以下內容。

 

 

AOT

在 Swifter 新版本里，AOT 的 JIT 的界限更加明顯，由 VersionDifferences.IsSupportEmit 字段標識；當這個字段為 true 表示當前平台是 JIT 運行時，Swifter 將在一些類中使用 Emit 技術提高性能；當此字段為 false 時，Swifter 會完全不使用 Emit 技術。

因我們設備有限，無法提供大規模的平台測試，但我們非常希望可以 Swifter 可以支持更多的平台，所以希望朋友們加 Swifter 交流 QQ 群：(133630914)，在這裏我們可以更快的提供反饋。

 

直接文檔讀取/寫入的 API

通常情況下，將小型對象序列化為 Json/MsgPack 和將小型 Json/MsgPack 反序列化為對象是 .NET 程序中常見的操作，Swifter 也正以此為常用場景做優化，所以 Swifter 在對小型數據操作時性能最佳，且相比其他 Json/MsgPack 解析庫優勢明顯。

但在大型數據下優勢減少，這主要原因是大型數據的存儲需要實體類或字典/集合存儲，創建/填充/遍歷這些對象消耗了大量資源（接口編程的損耗）；所以 Swifter 提供了直接讀取/寫入的 API 來繞開了對存儲介質的操作，以更快更小損耗的讀寫大型數據。

使用 JsonFormatter.CreateJsonReader/MessagePackFormatter.CreateMessagePackReader 函數來創建文檔讀取器，使用 JsonFormatter.CreateJsonWriter/MessagePackFormatter.CreateMessagePackWriter 函數來創建文檔寫入器。

使用文檔讀取器完整的讀取一個 Json/MsgPack 文檔將比反序列化為對象快 4-8 倍！使用文檔寫入器生成文檔的性能與將實體類序列化為 Json/MsgPack 相差較小，前提是您已構建好了這些對象。

讀取器演示：

寫入器演示：

 

擁有簡單預測數組的長度的能力

Swifter 在對小型數組，部分集合寫入時，會根據數組的類型，來源（Data,Json,MsgPack 等），名稱等信息並結合之前的一些長度記錄，簡單的預測出新的數組的長度；在寫入完成后，如果預測長度與實際長度不符，則擴展或壓縮為實際長度；如果與實際長度相符，則不需要重新創建新數組。此能力有效提高反序列化小型數組和部分集合性能，並且減少額外內存分配。

在其他高性能的 Json 解析庫，它們使用 ArrayPool<T> 同樣可以提高性能和減少內存分配；但是由於 Swifter 對兼容性的要求，使得我們不能使用 ArrayPool<T> 方案；在數組的長度比較穩定的情況下，我們的方案更好；但在數組長度非常不穩定的情況下，我們的方案可能仍需要 1-3 次的擴容/壓縮。

 

假定有序的對象反序列化

Swifter.Json 和 Swifter.MessagePack 都支持了假定有序的對象反序列化，當一個 Json/MsgPack 的對象與當前的實體類對象的字段順序一致時，將有效提升反序列化性能。

此操作默認不開啟，可以使用 AsOrderedObjectDeserialize 配置項開啟。

 

高性能的反射封裝

Swifter.Core 里提供了一些對反射封裝的類，它們放在 Swifter.Reflection 命名空間下；這些類型主要功能就是提高了系統反射的性能；XObjectRW 正是使用它們實現不依賴 Emit 的高性能對象讀寫器。

雖然放棄一些安全性檢查可以提高更多的性能，但是我們並沒有這麼做；我們仍然有類型安全檢查和防溢出檢查（事實上讀寫字段和屬性大多數的損害都在這裏，如果去掉這些檢查將得到上百倍的性能；事實上這些檢查只起到了提示程序員不能這麼做的作用，程序實際運行時這些檢查無意義）。

 

高效的数字 ToString 和 Parse 方法

Swifter.Core 提供了一些高性能数字算法，包括 Int64, UInt64, Double, Single, Decimal 的 Parse 和 ToString 算法，它們被放在 Swifter.Tools.NumberHelper 里，這些算法被應用與 Swifter.Json 和一些其他地方，這些算法支持 2-64 進制。

 

XConvert 萬能類型轉換器

Swifter.Tools.XConvert.Convert<TSource, TDestination> 是一個功能強大的萬能類型轉換函數，它在初始化時嘗試以下方式獲取合適的轉換函數：

(1) 包含在 System.Convert 里的基礎轉換函數；

(2) 類型兼容的隱式轉換（如：從子類轉換為父類，從 Int32 轉換為 Int64，從 Int64 轉換為 Double）。

(3) 原類型和目標類型中的 static implicit operator (隱式轉換) 函數。

(4) 原類型中的 ToXXX 實例函數。

(5) 目標類型中的 Parse 和 ValueOf 靜態函數。

(7) 目標類型的構造函數。

(8) 原類型和目標類型中的 static explicit operator (顯式轉換) 函數。

(9) 當以上方法都沒有找到合適函數時，將使用 (TDestination)(object)value 進行強制轉換。

簡單示例：

 

性能測試

ServiceStack.Json, Jil, LitJson, NetJson 等庫因為出錯太多未展示出來；如果有需要，您可以到 GitHub 上自行克隆/修改/運行，已收錄了 .NET 的大多數 Json 序列化庫。

 

更多實用功能等你發現…

Swifter.Core 還提供了許許多多的工具類，包括反射，委託，類型轉換，字符串，加密，哈希，数字，日期，數組和集合等工具，它們被放在 Swifter.Tools 命名空間下，您可以使用它們來提高開發效率和運行效率。

Swifter.RW 命名空間是整個 Swifter 框架的核心，它主要邏輯是：從讀取器中讀取值，寫入到寫入器中；如：從 JsonReader 讀取值到 ObjectWriter 或 DictionaryWriter 中；熟悉它們就等於精通了 Swifter 框架。

Swifter.Json/Swifter.MessagePack 有一個非常重要的配置項 JsonFormatterOptions/MessagePackFormatterOptions；使用前建議先閱讀它們，以配置更適合您系統的序列化和反序列化方案。

…

 

最後附上 Swifter.Data 的簡介

Swifter.Data 是一個小型的 ORM 工具，它相比 Dapper 性能要快一些，功能要強大一些。

 

感謝閱讀

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

【其他文章推薦】

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

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

※超省錢租車方案

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

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

※產品缺大量曝光嗎?你需要的是一流包裝設計!

一：背景

1. 講故事

最近同事在寫一段業務邏輯的時候，程序跑起來總是報：集合已修改；可能無法執行枚舉操作，硬是沒有找到什麼情況下會導致這個異常產生，就讓我來找一下bug，其實這個異常在座的每個程序員幾乎都遇到過，誰也不是一生下就是大牛，簡單看了下代碼，確實是多線程操作foreach，但並沒有對foreach進行Add，Remove操作，掃完代碼其實我也是有點懵，沒撤只能調試了，在foreach里套一層trycatch，查看異常的線程堆棧從而找出了問題代碼，代碼簡化如下：

        static void Main(string[] args)
        {
            var dict = new Dictionary<int, int>()
            {
                [1001] = 1,
                [1002] = 10,
                [1003] = 20
            };

            foreach (var userid in dict.Keys)
            {
                dict[userid] = dict[userid] + 1;
            }
        }

先尋找點安慰，說實話，憑肉眼你覺得這段代碼會拋出異常嗎？ 反正我是被騙過了，大寫的尷尬，結論如下，運行一下便知。

從圖中看確實是異常，說明在foreach的過程中連迭代集合的 value 都不可以修改，這讓我激起了強烈的探索欲，看看FCL中到底是怎麼限制的。

二：源碼探索

1. 從IL中尋找答案

C#已發展到 9.0 了，到處都充斥着語法糖，有時候不看一下底層的IL都不知道到底是轉化成了什麼，所以這個是必須的。

	IL_000d: callvirt instance void class [System.Collections]System.Collections.Generic.Dictionary`2<int32, int32>::set_Item(!0, !1)
	IL_001b: callvirt instance void class [System.Collections]System.Collections.Generic.Dictionary`2<int32, int32>::set_Item(!0, !1)
	IL_0029: callvirt instance void class [System.Collections]System.Collections.Generic.Dictionary`2<int32, int32>::set_Item(!0, !1)
	IL_0037: callvirt instance valuetype [System.Collections]System.Collections.Generic.Dictionary`2/KeyCollection/Enumerator<!0, !1> class [System.Collections]System.Collections.Generic.Dictionary`2/KeyCollection<int32, int32>::GetEnumerator()

	.try
	{
		IL_003d: br.s IL_005a
		// loop start (head: IL_005a)
			IL_003f: ldloca.s 1
			IL_0041: call instance !0 valuetype [System.Collections]System.Collections.Generic.Dictionary`2/KeyCollection/Enumerator<int32, int32>::get_Current()
			IL_004c: callvirt instance !1 class [System.Collections]System.Collections.Generic.Dictionary`2<int32, int32>::get_Item(!0)
			IL_0053: callvirt instance void class [System.Collections]System.Collections.Generic.Dictionary`2<int32, int32>::set_Item(!0, !1)
			IL_005a: ldloca.s 1
			IL_005c: call instance bool valuetype [System.Collections]System.Collections.Generic.Dictionary`2/KeyCollection/Enumerator<int32, int32>::MoveNext()
			IL_0061: brtrue.s IL_003f
		// end loop

		IL_0063: leave.s IL_0074
	} // end .try
	finally
	{

	} // end handler    

從IL代碼中可以看到，先執行了三次字典的索引器操作，然後調用了 Dictionary.GetEnumerator 來生成字典的迭代類，這思路就非常清晰了，然後我們看一下類索引器都做了些什麼。

從圖中可以看到，每一次的索引器操作，這裏都執行了version++，所以字典初始化完成之後，這裏的 version=3，沒有問題吧，然後繼續看代碼，尋找 Dictionary.GetEnumerator 方法啟動迭代類。

上面代碼的 _version = dictionary._version; 一定要看仔細了，在啟動迭代類的時候記錄了當時字典的版本號，也就是_version=3，然後繼續探索moveNext方法幹了什麼，如下圖：

從圖中可以看到，當每次執行moveNext的過程中，都會判斷一下字典的 version 和 當初初始化迭代類中的version 版本號是否一致，如果不一致就拋出異常，所以這行代碼就是點睛之筆了，當在foreach體中執行了 dict[userid] = dict[userid] + 1; 語句，相當於又執行了一次類索引器操作，這時候字典的version就變成 4 了，而當初初始化迭代類的時候還是3，自然下一次執行 moveNext 就是 3 != 4 拋出異常了。

如果你非要讓我證明給你看，這裏可以使用dnspy直接調試源碼，在異常那裡下一個斷點再查看兩個version版本號不就知道啦。。。

2. 面對疾風

有些朋友可能要說，碼農今天分享的這篇一點水準都沒有，我18年前就知道字典是不能動態修改的，還分析的頭頭是勁。

但是我有話要說，這個還確實是我的一個盲區，平時在迭代字典的時候value一般都是引用類型，動態修改引用類型的值自然是沒有問題的，這是因為你不管怎麼修改都不會改變 _version 版本號，但質疑我的也不要把話說的太滿，因為這種操作是非常語義化非常大眾的需求，你能保證後面net版本不支持這個嗎？？？ 如果你說不可能，那恭喜你，被我帶到坑裡面去啦。

下面我用原封不動的代碼在 .net 5 下跑一次，睜大眼睛好好看哦~~~

驚訝吧, 居然在 .Net 5 中可以的，接下來用ILSpy去查查底層源碼，.netcore 3.1 和 net5 中分別對 類索引器 都做了啥修改。

• netcore 3.1

Path： C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.1.2\System.Private.CoreLib.dll

• net5

Path： C:\Program Files\dotnet\shared\Microsoft.NETCore.App\5.0.0-preview.5.20278.1\System.Private.CoreLib.dll

對比兩張圖你會發現 .Net5 中並沒有做 _version++ 操作，這就了，如果你再細讀代碼，你還發現 .Net5 對字典進行了較大幅度的優化，哈哈，當初在 .Net5 之前產生的錯誤，在 .Net5 中居然沒有啦!

四： 總結

源碼面前，不談隱私，沒事多翻翻源碼，有可能還有意外收穫，比如在 .Net 5下的這點新發現，可能還是全網第一個哦，這要是兩個大牛爭吵，讓小白去相信誰呢，嘿嘿，源碼才是真正的專家~

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

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!

前言

上一篇【.Net Core微服務入門全紀錄（二）——Consul-服務註冊與發現（上）】已經成功將我們的服務註冊到Consul中，接下來就該客戶端通過Consul去做服務發現了。

服務發現

• 同樣Nuget安裝一下Consul：

• 改造一下業務系統的代碼：

ServiceHelper.cs：

    public class ServiceHelper : IServiceHelper
    {
        private readonly IConfiguration _configuration;

        public ServiceHelper(IConfiguration configuration)
        {
            _configuration = configuration;
        }

        public async Task<string> GetOrder()
        {
            //string[] serviceUrls = { "http://localhost:9060", "http://localhost:9061", "http://localhost:9062" };//訂單服務的地址，可以放在配置文件或者數據庫等等...

            var consulClient = new ConsulClient(c =>
            {
                //consul地址
                c.Address = new Uri(_configuration["ConsulSetting:ConsulAddress"]);
            });

            //consulClient.Catalog.Services().Result.Response;
            //consulClient.Agent.Services().Result.Response;
            var services = consulClient.Health.Service("OrderService", null, true, null).Result.Response;//健康的服務

            string[] serviceUrls = services.Select(p => $"http://{p.Service.Address + ":" + p.Service.Port}").ToArray();//訂單服務地址列表

            if (!serviceUrls.Any())
            {
                return await Task.FromResult("【訂單服務】服務列表為空");
            }

            //每次隨機訪問一個服務實例
            var Client = new RestClient(serviceUrls[new Random().Next(0, serviceUrls.Length)]);
            var request = new RestRequest("/orders", Method.GET);

            var response = await Client.ExecuteAsync(request);
            return response.Content;
        }

        public async Task<string> GetProduct()
        {
            //string[] serviceUrls = { "http://localhost:9050", "http://localhost:9051", "http://localhost:9052" };//產品服務的地址，可以放在配置文件或者數據庫等等...

            var consulClient = new ConsulClient(c =>
            {
                //consul地址
                c.Address = new Uri(_configuration["ConsulSetting:ConsulAddress"]);
            });

            //consulClient.Catalog.Services().Result.Response;
            //consulClient.Agent.Services().Result.Response;
            var services = consulClient.Health.Service("ProductService", null, true, null).Result.Response;//健康的服務

            string[] serviceUrls = services.Select(p => $"http://{p.Service.Address + ":" + p.Service.Port}").ToArray();//產品服務地址列表

            if (!serviceUrls.Any())
            {
                return await Task.FromResult("【產品服務】服務列表為空");
            }

            //每次隨機訪問一個服務實例
            var Client = new RestClient(serviceUrls[new Random().Next(0, serviceUrls.Length)]);
            var request = new RestRequest("/products", Method.GET);

            var response = await Client.ExecuteAsync(request);
            return response.Content;
        }
    }

appsettings.json：

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*",
  "ConsulSetting": {
    "ConsulAddress": "http://localhost:8500"
  }
}

OK，以上代碼就完成了服務列表的獲取。

瀏覽器測試一下：

隨便停止2個服務：

繼續訪問：

這時候停止的服務地址就獲取不到了，客戶端依然正常運行。

這時候解決了服務的發現，新的問題又來了…

• 客戶端每次要調用服務，都先去Consul獲取一下地址，這不僅浪費資源，還增加了請求的響應時間，這顯然讓人無法接受。

那麼怎麼保證不要每次請求都去Consul獲取地址，同時又要拿到可用的地址列表呢？
Consul提供的解決方案：——Blocking Queries （阻塞的請求）。詳情請見官網：https://www.consul.io/api-docs/features/blocking

Blocking Queries

這是什麼意思呢，簡單來說就是當客戶端請求Consul獲取地址列表時，需要攜帶一個版本號信息，Consul會比較這個客戶端版本號是否和Consul服務端的版本號一致，如果一致，則Consul會阻塞這個請求，直到Consul中的服務列表發生變化，或者到達阻塞時間上限；如果版本號不一致，則立即返回。這個阻塞時間默認是5分鐘，支持自定義。
那麼我們另外啟動一個線程去干這件事情，就不會影響每次的用戶請求了。這樣既保證了客戶端服務列表的準確性，又節約了客戶端請求服務列表的次數。

• 繼續改造代碼：
  IServiceHelper增加一個獲取服務列表的接口方法：

    public interface IServiceHelper
    {
        /// <summary>
        /// 獲取產品數據
        /// </summary>
        /// <returns></returns>
        Task<string> GetProduct();

        /// <summary>
        /// 獲取訂單數據
        /// </summary>
        /// <returns></returns>
        Task<string> GetOrder();

        /// <summary>
        /// 獲取服務列表
        /// </summary>
        void GetServices();
    }

ServiceHelper實現接口：

    public class ServiceHelper : IServiceHelper
    {
        private readonly IConfiguration _configuration;
        private readonly ConsulClient _consulClient;
        private ConcurrentBag<string> _orderServiceUrls;
        private ConcurrentBag<string> _productServiceUrls;

        public ServiceHelper(IConfiguration configuration)
        {
            _configuration = configuration;
            _consulClient = new ConsulClient(c =>
            {
                //consul地址
                c.Address = new Uri(_configuration["ConsulSetting:ConsulAddress"]);
            });
        }

        public async Task<string> GetOrder()
        {
            if (_productServiceUrls == null)
                return await Task.FromResult("【訂單服務】正在初始化服務列表...");

            //每次隨機訪問一個服務實例
            var Client = new RestClient(_orderServiceUrls.ElementAt(new Random().Next(0, _orderServiceUrls.Count())));
            var request = new RestRequest("/orders", Method.GET);

            var response = await Client.ExecuteAsync(request);
            return response.Content;
        }

        public async Task<string> GetProduct()
        {
            if(_productServiceUrls == null)
                return await Task.FromResult("【產品服務】正在初始化服務列表...");

            //每次隨機訪問一個服務實例
            var Client = new RestClient(_productServiceUrls.ElementAt(new Random().Next(0, _productServiceUrls.Count())));
            var request = new RestRequest("/products", Method.GET);

            var response = await Client.ExecuteAsync(request);
            return response.Content;
        }

        public void GetServices()
        {
            var serviceNames = new string[] { "OrderService", "ProductService" };
            Array.ForEach(serviceNames, p =>
            {
                Task.Run(() =>
                {
                    //WaitTime默認為5分鐘
                    var queryOptions = new QueryOptions { WaitTime = TimeSpan.FromMinutes(10) };
                    while (true)
                    {
                        GetServices(queryOptions, p);
                    }
                });
            });
        }
        private void GetServices(QueryOptions queryOptions, string serviceName)
        {
            var res = _consulClient.Health.Service(serviceName, null, true, queryOptions).Result;
            
            //控制台打印一下獲取服務列表的響應時間等信息
            Console.WriteLine($"{DateTime.Now}獲取{serviceName}：queryOptions.WaitIndex：{queryOptions.WaitIndex}  LastIndex：{res.LastIndex}");

            //版本號不一致 說明服務列表發生了變化
            if (queryOptions.WaitIndex != res.LastIndex)
            {
                queryOptions.WaitIndex = res.LastIndex;

                //服務地址列表
                var serviceUrls = res.Response.Select(p => $"http://{p.Service.Address + ":" + p.Service.Port}").ToArray();

                if (serviceName == "OrderService")
                    _orderServiceUrls = new ConcurrentBag<string>(serviceUrls);
                else if (serviceName == "ProductService")
                    _productServiceUrls = new ConcurrentBag<string>(serviceUrls);
            }
        }
    }

Startup的Configure方法中調用一下獲取服務列表：

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env, IServiceHelper serviceHelper)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }
            else
            {
                app.UseExceptionHandler("/Home/Error");
            }
            app.UseStaticFiles();

            app.UseRouting();

            app.UseAuthorization();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllerRoute(
                    name: "default",
                    pattern: "{controller=Home}/{action=Index}/{id?}");
            });

            //程序啟動時 獲取服務列表
            serviceHelper.GetServices();
        }

代碼完成，運行測試：

現在不用每次先請求服務列表了，是不是流暢多了？

看一下控制台打印：

這時候如果服務列表沒有發生變化的話，獲取服務列表的請求會一直阻塞到我們設置的10分鐘。

隨便停止2個服務：

這時候可以看到，數據被立馬返回了。

繼續訪問客戶端網站，同樣流暢。
（gif圖傳的有點問題。。。）

至此，我們就通過Consul完成了服務的註冊與發現。
接下來又引發新的思考。。。

1. 每個客戶端系統都去維護這一堆服務地址，合理嗎？
2. 服務的ip端口直接暴露給所有客戶端，安全嗎？
3. 這種模式下怎麼做到客戶端的統一管理呢？
   …

代碼放在：https://github.com/xiajingren/NetCoreMicroserviceDemo

未完待續…

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

【其他文章推薦】

※超省錢租車方案

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

※回頭車貨運收費標準

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

※產品缺大量曝光嗎?你需要的是一流包裝設計!

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

目錄

一.介紹

二.問題提出

　　2.1內存原理圖

　　2.2幾個問題

三.回答問題

　　3.1為什麼會出現內存泄漏

　　3.2若Entry使用弱引用

　　3.3弱引用配合自動回收

四.總結　　

 

 

 

一.介紹

　　之前使用ThreadLocal的時候，就聽過ThreadLocal怎麼怎麼的可能會出現內存泄漏，具體原因也沒去深究，就是一種不清不楚的狀態。最近在看JDK的源碼，其中就包含ThreadLocal，在對ThreadLocal的使用場景介紹以及源碼的分析后，對於ThreadLocal中可能存在的內存泄漏問題也搞清楚了，所以這裏專門寫一篇博客分析一下。

　　在分析內存泄漏之前，先了解2個概念，就是內存泄漏和內存溢出：

　　內存溢出（memory overflow）：是指不能申請到足夠的內存進行使用，就會發生內存溢出，比如出現的OOM（Out Of Memory）

　　內存泄漏（memory lack）：內存泄露是指在程序中已經動態分配的堆內存由於某種原因未釋放或者無法釋放（已經沒有用處了，但是沒有釋放），造成系統內存的浪費，這種現象叫“內存泄露”。

　　當內存泄露到達一定規模后，造成系統能申請的內存較少，甚至無法申請內存，最終導致內存溢出，所以內存泄露是導致內存溢出的一個原因。

 

二.問題提出

2.1內存原理圖

　　下圖是程序運行中的內存分布圖，簡要介紹一下這種圖：當前線程有一個threadLocals屬性（ThreadLocalMap屬性），該map的底層是數組，每個數組元素時Entry類型，Entry類型的key是ThreadLocal類型（也就是創建的ThreadLocal對象），而value是則是ThreadLocal.set()方法設置的value。

　　

　　需要注意的是ThreadLocalMap的Entry，繼承自弱引用，定義如下，關於Java的引用介紹，可以參考：Java-強引用、軟引用、弱引用、虛引用

/**
 * ThreadLocalMap中存放的元素類型，繼承了弱引用類
 */
static class Entry extends WeakReference<ThreadLocal<?>> {
    // key對應的value，注意key是ThreadLocal類型
    Object value;

    Entry(ThreadLocal<?> k, Object v) {
        super(k);
        value = v;
    }
}

 

2.2問題提出

　　在看了上面ThreadLocal和ThreadLocalMap相關的內存分佈以及關聯后，提出這樣幾個問題：

　　1.ThreadLocal為什麼會出現內存溢出？

　　2.Entry的key為什麼要用弱引用？

　　3.使用弱引用是否就能解決內存溢出？

　　為了回答上面這3個問題，我寫了一段代碼，後面根據這段代碼進行分析：

public void step1() {
    // some action
    
    step2();
    step3();
    
    // other action
}

// 在stepX中都會創建threadLocal對象
public void step2() {
    ThreadLocal<String> tl = new ThreadLocal<>();
    tl.set("this is value");
}
public void step3() {
    ThreadLocal<Integer> tl = new ThreadLocal<>();
    tl.set(99);
}

　　在step1中會調用step2和step3，step2和step3都會創建ThreadLocal對象，當step2和step3執行完畢后，其中的棧內存中ThreadLocal引用就會被清除。

 

三.回答問題

 

　　

　　現在針對這個圖，一步一步的分析問題，中途會得出一些臨時的結論，但是最終的結論才是正確的。

 

3.1為什麼會出現內存泄露

　　現在有2點假設，本小節的分析都是基於這兩個假設之上的：

　　1.Entry的key使用強引用，key對ThreadLocal對象使用強引用，也就是上面圖中連線5是強引用（key強引用ThreadLocal對象）；

　　2.ThreadLocalMap中不會對過期的Entry進行清理。

　　上面代碼中，如果ThreadLocalMap的key使用強引用，那麼即使棧內存的ThreadLocal引用被清除，但是堆中的ThreadLocal對象卻並不會被清除，這是因為ThreadLocalMap中Entry的key對ThreadLocal對象是強引用。

　　如果當前線程不結束，那麼堆中的ThreadLocal對象將會一直存在，對應的內存就不會被回收，與之關聯的Entry也不會被回收（Entry對應的value也不會被回收），當這種情況出現數量比較多的時候，未釋放的內存就會上升，就可能出現內存泄漏的問題。

　　上面的結論是暫時的，有前提假設！！！最終結論還需要看後面分析。

 

3.2若Entry使用弱引用

　　

　　仍舊有1個假設，就是ThreadLocalMap中不會對過期的Entry進行清理，陳舊的Entry是指Entry的key為null。

　　按照源碼，Entry繼承弱引用，其Key對ThreadLocal是弱引用，也就是上圖中連線5是弱引用，連線6仍為強引用。

　　同樣以上面代碼為例，step2和step3創建了ThreadLocal對象，step2和step3執行完后，棧中的ThreadLocal引用被清除了；由於堆內存中ThreadLocalMap的Entry key弱引用ThreadLocal對象，根據垃圾收集器對弱引用對象的處理：

當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象。

　　此時堆中ThreadLocal對象會被gc回收（因為現在沒有對ThreadLocal的強引用，只有一個弱引用ThreadLocal對象），Entry的key為null，但是value不為null，且value也是強引用（連線6），所以Entry仍舊不能回收，只能釋放ThreadLocal的內存，仍舊可能導致內存泄漏。

　　在沒有自動清理陳舊Entry的前提下，即使Entry使用弱引用，仍可能出現內存泄漏。

 

3.3弱引用配合自動回收

　　通過3.2的分析，其實只要陳舊的Entry能自動被回收，就能解決內存泄漏的問題，其實JDK就是這麼做的。

　　如果看過源碼，就知道，ThreadLocalMap底層使用數組來保存元素，使用“線性探測法”來解決hash衝突，關於線性探測法的介紹可以查看：利用線性探測法解決hash衝突

　　在每次調用ThreadLocal類的get、set、remove這些方法的時候，內部其實都是對ThreadLocalMap進行操作，對應ThreadLocalMap的get、set、remove操作。

　　重點來了！重點來了！重點來了！

　　ThreadLocalMap的每次get、set、remove，都會清理過期的Entry，下面以get操作解釋，其他操作也是一個意思，大致如下：

　　1.ThreadLocalMap底層用數組保存元素，當get一個Entry時，根據key的hash值（非hashCode）計算出該Entry應該出在什麼位置；

　　2.計算出的位置可能會有衝突，比如預期位置是position=5，但是position=5的位置已經有其他Entry了；

　　3.出現衝突后，會使用線性探測法，找position=6位置上的Entry是否匹配（匹配是指hash相同），如果匹配，則返回position=6的Entry。

　　4.在這個過程中，如果position=5位置上的Entry已經是陳舊的Entry（Entry的key為null），此時position=5的key就應該被清理；

　　5.光清理position=5的Entry還不夠，為了保證線性探測法的規則，需要判斷數組中的其他元素是否需要調整位置（如果需要，則調整位置），在這個過程中，也會進行清理陳舊Entry的操作。

　　上面這5個步驟就保證了每次get都會清理數組中（map）的陳舊Entry，清理一個陳舊的Entry，就是下面這三行代碼：

Entry.value = null; // 將Entry的value設為null
table[index] = null;// 將數組中該Entry的位置設置null
size--;	// map的size減一

　　對於ThreadLocal的set、remove也類似這個原理。

　　有了自動回收陳舊Entry的操作，需要注意的是，在這個時候，key使用弱引用就是至關重要的一點！！！

　　因為key使用弱引用后，當弱引用的ThreadLocal對象被會回收后，該key的引用為null，則該Entry在下一次get、set、remove的時候就才會被清理，從未避免內存泄漏的問題。

　　

四.總結

　　在上面的分析中，看到ThreadLocal基本不會出現內存泄漏的問題了，因為ThreadLocalMap中會在get、set、remove的時候清理陳舊的Entry，與Entry的key使用弱引用密不可分。

　　當然我們也可以在代碼中手動調用ThreadLocal的remove方法進行清除map中key為該threadLocal對象的Entry，同時清理過期的Entry。

　　

 

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案