程序員需要了解的硬核知識之二進制

1{icon} {views}

我們都知道,計算機的底層都是使用二進制數據進行數據流傳輸的,那麼為什麼會使用二進製表示計算機呢?或者說,什麼是二進制數呢?在拓展一步,如何使用二進制進行加減乘除?二進制數如何表示負數呢?本文將一一為你揭曉。

為什麼用二進製表示

我們大家知道,計算機內部是由IC电子元件組成的,其中 CPU內存 也是 IC 电子元件的一種,CPU和內存圖如下

CPU 和 內存使用IC电子元件作為基本單元,IC电子元件有不同種形狀,但是其內部的組成單元稱為一個個的引腳。有人說CPU 和 內存內部都是超大規模集成電路,其實IC 就是集成電路(Integrated Circuit)。

IC元件兩側排列的四方形塊就是引腳,IC的所有引腳,只有兩種電壓: 0V5V,IC的這種特性,也就決定了計算機的信息處理只能用 0 和 1 表示,也就是二進制來處理。一個引腳可以表示一個 0 或 1 ,所以二進制的表示方式就變成 0、1、10、11、100、101等,雖然二進制數並不是專門為 引腳 來設計的,但是和 IC引腳的特性非常吻合。

計算機的最小集成單位為 ,也就是 比特(bit),二進制數的位數一般為 8位、16位、32位、64位,也就是 8 的倍數,為什麼要跟 8 扯上關係呢? 因為在計算機中,把 8 位二進制數稱為 一個字節, 一個字節有 8 位,也就是由 8個bit構成。

為什麼1個字節等於8位呢?因為 8 位能夠涵蓋所有的字符編碼,這個記住就可以了。

字節是最基本的計量單位,位是最小單位。

用字節處理數據時,如果数字小於存儲數據的字節數 ( = 二進制的位數),那麼高位就用 0 填補,高位和數學的數字錶示是一樣的,左側表示高位,右側表示低位。比如 這個六位數用二進制數來表示就是 100111,只有6位,高位需要用 0 填充,填充完后是 00100111,佔一個字節,如果用 16 位表示 就是 0000 0000 0010 0111佔用兩個字節。

我們一般口述的 32 位和 64位的計算機一般就指的是處理位數,32 位一次可以表示 4個字節,64位一次可以表示8個字節的二進制數。

我們一般在軟件開發中用十進制數表示的邏輯運算等,也會被計算機轉換為二進制數處理。對於二進制數,計算機不會區分他是 圖片、音頻文件還是数字,這些都是一些數據的結合體。

什麼是二進制數

那麼什麼是二進制數呢?為了說明這個問題,我們先把 00100111 這個數轉換為十進制數看一下,二進制數轉換為十進制數,直接將各位置上的值 * 位權即可,那麼我們將上面的數值進行轉換

也就是說,二進制數代表的 00100111 轉換成十進制就是 39,這個 39 並不是 3 和 9 兩個数字連着寫,而是 3 * 10 + 9 * 1,這裏面的 10 , 1 就是位權,以此類推,上述例子中的位權從高位到低位依次就是 7 6 5 4 3 2 1 0 。這個位權也叫做次冪,那麼最高位就是2的7次冪,2的6次冪 等等。二進制數的運算每次都會以2為底,這個2 指得就是基數,那麼十進制數的基數也就是 10 。在任何情況下位權的值都是 數的位數 – 1,那麼第一位的位權就是 1 – 1 = 0, 第二位的位權就睡 2 – 1 = 1,以此類推。

那麼我們所說的二進制數其實就是 用0和1兩個数字來表示的數,它的基數為2,它的數值就是每個數的位數 * 位權再求和得到的結果,我們一般來說數值指的就是十進制數,那麼它的數值就是 3 * 10 + 9 * 1 = 39。

移位運算和乘除的關係

在了解過二進制之後,下面我們來看一下二進制的運算,和十進制數一樣,加減乘除也適用於二進制數,只要注意逢 2 進位即可。二進制數的運算,也是計算機程序所特有的運算,因此了解二進制的運算是必須要掌握的。

首先我們來介紹移位 運算,移位運算是指將二進制的數值的各個位置上的元素坐左移和右移操作,見下圖

上述例子中還是以 39 為例,我們先把十進制的39 轉換為二進制的 0010 0111,然後向左移位 << 一個字節,也就變成了 0100 1110,那麼再把此二進制數轉換為十進制數就是上面的78, 十進制的78 竟然是 十進制39 的2倍關係。我們在讓 0010 0111 左移兩位,也就是 1001 1100,得出來的值是 156,相當於擴大了四倍!

因此你可以得出來此結論,左移相當於是數值擴大的操作,那麼右移 >> 呢?按理說右移應該是縮小 1/2,1/4 倍,但是39 縮小二倍和四倍不就變成小數了嗎?這個怎麼表示呢?請看下一節

便於計算機處理的補數

剛才我們沒有介紹右移的情況,是因為右移之後空出來的高位數值,有 0 和 1 兩種形式。要想區分什麼時候補0什麼時候補1,首先就需要掌握二進制數表示負數的方法。

二進制數中表示負數值時,一般會把最高位作為符號來使用,因此我們把這個最高位當作符號位。 符號位是 0 時表示正數,是 1 時表示 負數。那麼 -1 用二進制數該如何表示呢?可能很多人會這麼認為: 因為 1 的二進制數是 0000 0001,最高位是符號位,所以正確的表示 -1 應該是 1000 0001,但是這個答案真的對嗎?

計算機世界中是沒有減法的,計算機在做減法的時候其實就是在做加法,也就是用加法來實現的減法運算。比如 100 – 50 ,其實計算機來看的時候應該是 100 + (-50),為此,在表示負數的時候就要用到二進制補數,補數就是用正數來表示的負數。

為了獲得補數,我們需要將二進制的各數位的數值全部取反,然後再將結果 + 1 即可,先記住這個結論,下面我們來演示一下。

具體來說,就是需要先獲取某個數值的二進制數,然後對二進制數的每一位做取反操作(0 —> 1 , 1 —> 0),最後再對取反后的數 +1 ,這樣就完成了補數的獲取。

補數的獲取,雖然直觀上不易理解,但是邏輯上卻非常嚴謹,比如我們來看一下 1 – 1 的這個過程,我們先用上面的這個 1000 0001(它是1的補數,不知道的請看上文,正確性先不管,只是用來做一下計算)來表示一下

奇怪,1 – 1 會變成 130 ,而不是0,所以可以得出結論 1000 0001 表示 -1 是完全錯誤的。

那麼正確的該如何表示呢?其實我們上面已經給出結果了,那就是 1111 1111,來論證一下它的正確性

我們可以看到 1 – 1 其實實際上就是 1 + (-1),對 -1 進行上面的取反 + 1 后變為 1111 1111, 然後與 1 進行加法運算,得到的結果是九位的 1 0000 0000,結果發生了溢出,計算機會直接忽略掉溢出位,也就是直接拋掉 最高位 1 ,變為 0000 0000。也就是 0,結果正確,所以 1111 1111 表示的就是 -1 。

所以負數的二進製表示就是先求其補數,補數的求解過程就是對原始數值的二進制數各位取反,然後將結果 + 1

當然,結果不為 0 的運算同樣也可以通過補數求得正確的結果。不過,有一點需要注意,當運算結果為負的時候,計算結果的值也是以補數的形式出現的,比如 3 – 5 這個運算,來看一下解析過程

3 – 5 的運算,我們按着上面的思路來過一遍,計算出來的結果是 1111 1110,我們知道,這個數值肯定表示負數,但是負數無法直接用十進製表示,需要對其取反+ 1,算出來的結果是 2,因為 1111 1110的高位是 1,所以最終的結果是 -2。

編程語言的數據類型中,有的可以處理負數,有的不可以。比如 C語言中不能處理負數的 unsigned short類型,也有能處理負數的short類型 ,都是兩個字節的變量,它們都有 2 的十六次冪種值,但是取值範圍不一樣,short 類型的取值範圍是 -32768 – 32767 , unsigned short 的取值範圍是 0 – 65536。

仔細思考一下補數的機制,就能明白 -32768 比 32767 多一個數的原因了,最高位是 0 的正數有 0 ~ 32767 共 32768 個,其中包括0。最高位是 1 的負數,有 -1 ~ -32768 共 32768 個,其中不包含0。0 雖然既不是正數也不是負數,但是考慮到其符號位,就將其歸為了正數。

算數右移和邏輯右移的區別

在了解完補數后,我們重新考慮一下右移這個議題,右移在移位后空出來的最高位有兩種情況 0 和 1。當二進制數的值表示圖形模式而非數值時,移位后需要在最高位補0,類似於霓虹燈向右平移的效果,這就被稱為邏輯右移

將二進制數作為帶符號的數值進行右移運算時,移位后需要在最高位填充移位前符號位的值( 0 或 1)。這就被稱為算數右移。如果數值使用補數表示的負數值,那麼右移后在空出來的最高位補 1,就可以正確的表示 1/2,1/4,1/8等的數值運算。如果是正數,那麼直接在空出來的位置補 0 即可。

下面來看一個右移的例子。將 -4 右移兩位,來各自看一下移位示意圖

如上圖所示,在邏輯右移的情況下, -4 右移兩位會變成 63, 顯然不是它的 1/4,所以不能使用邏輯右移,那麼算數右移的情況下,右移兩位會變為 -1,顯然是它的 1/4,故而採用算數右移。

那麼我們可以得出來一個結論:左移時,無論是圖形還是數值,移位后,只需要將低位補 0 即可;右移時,需要根據情況判斷是邏輯右移還是算數右移。

下面介紹一下符號擴展:將數據進行符號擴展是為了產生一個位數加倍、但數值大小不變的結果,以滿足有些指令對操作數位數的要求,例如倍長於除數的被除數,再如將數據位數加長以減少計算過程中的誤差。

以8位二進製為例,符號擴展就是指在保持值不變的前提下將其轉換成為16位和32位的二進制數。將0111 1111這個正的 8位二進制數轉換成為 16位二進制數時,很容易就能夠得出0000 0000 0111 1111這個正確的結果,但是像 1111 1111這樣的補數來表示的數值,該如何處理?直接將其表示成為1111 1111 1111 1111就可以了。也就是說,不管正數還是補數表示的負數,只需要將 0 和 1 填充高位即可。

邏輯運算的竅門

掌握邏輯和運算的區別是:將二進制數表示的信息作為四則運算的數值來處理就是算數,像圖形那樣,將數值處理為單純的 01 的羅列就是邏輯

計算機能夠處理的運算,大體可分為邏輯運算和算數運算,算數運算指的是加減乘除四則運算;邏輯運算指的是對二進制各個數位的 0 和 1分別進行處理的運算,包括邏輯非(NOT運算)、邏輯與(AND運算)、邏輯或(OR運算)和邏輯異或(XOR運算)四種。

  • 邏輯非 指的是將 0 變成 1,1 變成 0 的取反操作
  • 邏輯與 指的是”兩個都是 1 時,運算結果才是 1,其他情況下是 0″
  • 邏輯或 指的是”至少有一方是 1 時,運算結果為 1,其他情況下運算結果都是 0″
  • 邏輯異或 指的是 “其中一方是 1,另一方是 0時運算結果才是 1,其他情況下是 0”

掌握邏輯運算的竅門,就是要摒棄二進制數表示數值這一個想法。大家不要把二進制數表示的值當作數值,應該把它看成是 開關上的 ON/OFF

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家公司費用怎麼算?

【asp.net core 系列】6 實戰之 一個項目的完整結構

1{icon} {views}

0. 前言

在《asp.net core 系列》之前的幾篇文章中,我們簡單了解了路由、控制器以及視圖的關係以及靜態資源的引入,讓我們對於asp.net core mvc項目有了基本的認識。不過,這些並不是 asp.net core mvc項目的全部內容,剩下的內容我將結合實戰項目為大家講解其中的知識。現在,就讓我們開始吧。

1. 項目構建

拋開之前的項目,現在跟着我重新創建一個項目,第一步依舊是先創建一個解決方案:

dotnet new sln --name Template

我先介紹一下這個項目(指整個項目,不是單獨的asp.net core 應用),這是一個後台管理的模板應用,提供了常見後台系統(管理員端)的功能,包括員工管理、部門管理、角色管理等功能。

現在回到項目中,通常一個項目需要一個模型層,一個數據提供層以及web展示層。然後,我們依次創建 Data、Domain、Web 三個項目,其中Data和Domain 是 classlib,Web是mvc項目。

# 確保當前目錄與 Template.sln 處於相同的目錄
dotnet new classlib --name Data
dotnet new classlib --name Domain
dotnet new mvc --name Web

添加三個項目到解決方案中:

dotnet sln add Data
dotnet sln add Domain
dotnet sln add Web

因為Data 中存放着模型層,所以需要其他項目對它有一個引用:

cd Domain
dotnet add reference ../Data
cd ../Web
dotnet add reference ../Data

當然,實際開發中我們應當還有一個Service層,這一層用來存放業務代碼,減少控制器里不必要的業務代碼。那麼繼續:

# 回到項目的根目錄
cd ..
dotnet new classlib --name Service
dotnet sln add Service

然後添加Service的引用:

cd Service
dotnet add reference ../Data

將 Service的引用添加到Web里:

cd ../Web
dotnet add reference ../Service

現在一個大型工程基本都是面向接口編程,幾個關鍵層應當都是接口層,我們實際上還缺少Domain的實現層和Service的實現層。

cd ..
dotnet new classlib --name Domain.Implements
dotnet new classlib --name Service.Implements

在對應的實現層中,引入它們實現的接口層,並引入Data:

cd Domain.Implements
dotnet add reference ../Data
dotnet add reference ../Domain
cd ../Service.Implements
dotnet add reference ../Data
dotnet add reference ../Domain
dotnet add reference ../Service

這裡在Service的實現層添加Domain接口層的引用,而不是實現層的引用。這是因為面向接口編程,我們需要對Service實現層隱藏Domain的實現,所以對於Service的實現層來說,不需要關心Domain層的實現邏輯。

在Web中添加新建的兩個實現層的引用:

cd ../Web
dotnet add reference ../Domain.Implements
dotnet add reference ../Service.Implements

添加這兩個實現層到解決方案中:

cd ..
dotnet sln add Domain.Implements
dotnet sln add Service.Implements

下圖是到目前為止的項目結構圖:

整體而言,Data是各個層之間的數據流通依據,所以各個項目都依賴於此項目,各個接口層的實現層都只對Web可見,其他各層實際上並不清楚具體實現。

隱藏實現層有什麼好處呢?

  • 調用方不知道實現方的邏輯,避免調用方對特定實現的依賴
  • 有利於團隊協作,有的團隊是針對模塊劃分,有的是針對分層劃分,無論哪種,使用接口都是一個好的選擇
  • 有利於後期優化,可以很方便的切換實現層,而不用重新編譯過多的代碼

當然,並不只有這些好處,不過這樣有一個壞處,在web層調用service層時會更繁瑣,不過這也不是不可解決的,後續的內容中會為大家介紹如何解決這個煩惱。

2. 項目補充

通常情況下,一個完整的項目還會有一個工具類項目和一個測試項目。所以,繼續添加以下項目:

dotnet new classlib --name Utils

Utils 表示工具類,通常一個項目中工具類會比較多,所以就抽成了一個項目,單獨列出來。

添加測試項目:

dotnet new nunit --name Test

這裏使用的是nunit 3測試框架,當然還有另一個是xunit測試框架。

添加兩個項目到解決方案里:

dotnet sln add Utils
dotnet sln add Test

3. 總結

本章內容旨在通過創建項目,讓大家了解實際開發中項目的層級規劃思想,這並不代表我的就是最優的,只是這是我總結出來相對方便的層級關係。這裏並沒有講解如何通過Visual Studio或者Rider創建這樣的一個項目,我希望大夥能夠自己試試。

好了,希望大家能創建好項目,當然了後期我會給大家提供這個項目的源碼的,地址暫時保密哦。

更多內容煩請關注我的博客《高先生小屋》

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

Netty源碼學習系列之4-ServerBootstrap的bind方法

1{icon} {views}

前言

    今天研究ServerBootstrap的bind方法,該方法可以說是netty的重中之重、核心中的核心。前兩節的NioEventLoopGroup和ServerBootstrap的初始化就是為bind做準備。照例粘貼一下這個三朝元老的demo,開始本文內容。

 1 public class NettyDemo1 {
 2     // netty服務端的一般性寫法
 3     public static void main(String[] args) {
 4         EventLoopGroup boss = new NioEventLoopGroup(1);
 5         EventLoopGroup worker = new NioEventLoopGroup();
 6         try {
 7             ServerBootstrap bootstrap = new ServerBootstrap();
 8             bootstrap.group(boss, worker).channel(NioServerSocketChannel.class)
 9                     .option(ChannelOption.SO_BACKLOG, 100)
10                     .handler(new NettyServerHandler())
11                     .childHandler(new ChannelInitializer<SocketChannel>() {
12                         @Override
13                         protected void initChannel(SocketChannel socketChannel) throws Exception {
14                             ChannelPipeline pipeline = socketChannel.pipeline();
15                             pipeline.addLast(new StringDecoder());
16                             pipeline.addLast(new StringEncoder());
17                             pipeline.addLast(new NettyServerHandler());
18                         }
19                     });
20             ChannelFuture channelFuture = bootstrap.bind(90);
21             channelFuture.channel().closeFuture().sync();
22         } catch (Exception e) {
23             e.printStackTrace();
24         } finally {
25             boss.shutdownGracefully();
26             worker.shutdownGracefully();
27         }
28     }
29 }

 

一、bind及doBind方法

1.ServerBootstrap.bind方法

    該方法有多個重載方法,但核心作用只有一個,就是將參數轉為InetSocketAddress對象傳給 —>

1 public ChannelFuture bind(int inetPort) {
2         return bind(new InetSocketAddress(inetPort));
3     }
1 public ChannelFuture bind(String inetHost, int inetPort) {
2         return bind(SocketUtils.socketAddress(inetHost, inetPort));
3     }
1 public ChannelFuture bind(InetAddress inetHost, int inetPort) {
2         return bind(new InetSocketAddress(inetHost, inetPort));
3     }

    下面這個bind方法,在該方法中調用了doBind方法。

1 public ChannelFuture bind(SocketAddress localAddress) {
2         validate();
3         return doBind(ObjectUtil.checkNotNull(localAddress, "localAddress"));
4     }

2、ServerBootstrap的doBind方法

    doBind方法位於父類AbstractBootstrap中,它有兩大功能,均在下面代碼中標識了出來,它們分別對應通過原生nio進行server端初始化時的兩個功能,第1步對應將channel註冊到selector上;第2步對應將server地址綁定到channel上。

 1 private ChannelFuture doBind(final SocketAddress localAddress) {
 2         final ChannelFuture regFuture = initAndRegister(); // 1)、初始化和註冊,重要***
 3         final Channel channel = regFuture.channel();
 4         if (regFuture.cause() != null) {
 5             return regFuture;
 6         }
 7 
 8         if (regFuture.isDone()) {
 9             // At this point we know that the registration was complete and successful.
10             ChannelPromise promise = channel.newPromise();
11             doBind0(regFuture, channel, localAddress, promise); // 2)、將SocketAddress和channel綁定起來,最終執行的是nio中的功能,重要**
12             return promise;
13         } else {
14             // 省略異常判斷、添加監聽器和異步調用doBind0方法
15         }
16     }

    為方便關聯對照,下面再粘貼一個簡單的原生NIO編程的服務端初始化方法,其實doBind方法的邏輯基本就是對下面這個方法的封裝,只是增加了很多附加功能。

    因為上述兩步都有些複雜,所以此處分兩部分進行追蹤。

二、AbstractBootstrap的initAndRegister方法

     該方法代碼如下所示,一共有三個核心方法,邏輯比較清晰,將channel new出來,初始化它,然後註冊到selector上。下面我們各個擊破。

 1 final ChannelFuture initAndRegister() {
 2         Channel channel = null;
 3         try { // 1)、實例化channel,作為服務端初始化的是NioServerSocketChannel
 4             channel = channelFactory.newChannel();
 5             init(channel); // 2)、初始化channel,即給channel中的屬性賦值
 6         } catch (Throwable t) {
 7             if (channel != null) {
 8                 channel.unsafe().closeForcibly();
 9                 return new DefaultChannelPromise(channel, GlobalEventExecutor.INSTANCE).setFailure(t);
10             }
11             return new DefaultChannelPromise(new FailedChannel(), GlobalEventExecutor.INSTANCE).setFailure(t);
12         }
13         // 3)、註冊,即最終是將channel 註冊到selector上
14         ChannelFuture regFuture = config().group().register(channel);
15         if (regFuture.cause() != null) {
16             if (channel.isRegistered()) {
17                 channel.close();
18             } else {
19                 channel.unsafe().closeForcibly();
20             }
21         }
22         return regFuture;
23     }

1、channelFactory.newChannel()方法

1 @Override
2     public T newChannel() {
3         try {
4             return constructor.newInstance();
5         } catch (Throwable t) {
6             throw new ChannelException("Unable to create Channel from class " + constructor.getDeclaringClass(), t);
7         }
8     }

    該方法完成了channel的實例化,channelFactory的賦值可參見上一篇博文【Netty源碼學習系列之3-ServerBootstrap的初始化】(地址 https://www.cnblogs.com/zzq6032010/p/13027161.html),對服務端來說,這裏channelFactory值為ReflectiveChannelFactory,且其內部的constructor是NioServerSocketChannel的無參構造器,下面追蹤NioServerSocketChannel的無參構造方法。

1.1)、new NioServerSocketChannel()

1 public NioServerSocketChannel() {
2         this(newSocket(DEFAULT_SELECTOR_PROVIDER));
3     }
 1 private static final SelectorProvider DEFAULT_SELECTOR_PROVIDER = SelectorProvider.provider();
 2 
 3 private static ServerSocketChannel newSocket(SelectorProvider provider) {
 4         try {
 5             return provider.openServerSocketChannel();
 6         } catch (IOException e) {
 7             throw new ChannelException(
 8                     "Failed to open a server socket.", e);
 9         }
10     }

    可見,它先通過newSocket方法獲取nio原生的ServerSocketChannel,然後傳給了重載構造器,如下,其中第三行是對NioServerSocketChannelConfig  config進行了賦值,邏輯比較簡單,下面主要看對父類構造方法的調用。

1 public NioServerSocketChannel(ServerSocketChannel channel) {
2         super(null, channel, SelectionKey.OP_ACCEPT);
3         config = new NioServerSocketChannelConfig(this, javaChannel().socket());
4     }

1.2)、對NioServerSocketChannel父類構造方法的調用

 1 protected AbstractNioChannel(Channel parent, SelectableChannel ch, int readInterestOp) {
 2         super(parent);
 3         this.ch = ch;
 4         this.readInterestOp = readInterestOp;
 5         try {
 6             ch.configureBlocking(false);
 7         } catch (IOException e) {
 8             try {
 9                 ch.close();
10             } catch (IOException e2) {
11                 if (logger.isWarnEnabled()) {
12                     logger.warn(
13                             "Failed to close a partially initialized socket.", e2);
14                 }
15             }
16 
17             throw new ChannelException("Failed to enter non-blocking mode.", e);
18         }
19     }

    中間經過了AbstractNioMessageChannel,然後調到下面AbstractNioChannel的構造方法。此時parent為null,ch為上面獲取到的nio原生ServerSocketChannel,readInterestOp為SelectionKey的Accept事件(值為16)。可以看到,將原生渠道ch賦值、感興趣的事件readInterestOp賦值、設置非阻塞。然後重點看對父類構造器的調用。

1.3)、AbstractChannel構造器

1 protected AbstractChannel(Channel parent) {
2         this.parent = parent;
3         id = newId();
4         unsafe = newUnsafe();
5         pipeline = newChannelPipeline();
6     }

    可以看到,此構造方法只是給四個屬性進行了賦值,我們挨個看下這四個屬性。

    第一個屬性是this.parent,類型為io.netty.channel.Channel,但此時值為null;

    第二個屬性id類型為io.netty.channel.ChannelId,就是一個id生成器,值為new DefaultChannelId();

    第三個屬性unsafe類型為io.netty.channel.Channel.Unsafe,該屬性很重要,封裝了對事件的處理邏輯,最終調用的是AbstractNioMessageChannel中的newUnsafe方法,賦的值為new NioMessageUnsafe();

    第四個屬性pipeline類型為io.netty.channel.DefaultChannelPipeline,該屬性很重要,封裝了handler處理器的邏輯,賦的值為 new DefaultChannelPipeline(this)  this即當前的NioServerSocketChannel對象。

    其中DefaultChannelPipeline的構造器需要額外看一下,如下,將NioServerSocketChannel對象存入channel屬性,然後初始化了tail、head兩個成員變量,且對應的前後指針指向對方。TailContext和HeadContext都繼承了AbstractChannelHandlerContext,在這個父類裏面維護了next和prev兩個雙向指針,看到這裡有經驗的園友應該一下子就能看出來,DefaultChannelPipeline內部維護了一個雙向鏈表。

 1 protected DefaultChannelPipeline(Channel channel) {
 2         this.channel = ObjectUtil.checkNotNull(channel, "channel");
 3         succeededFuture = new SucceededChannelFuture(channel, null);
 4         voidPromise =  new VoidChannelPromise(channel, true);
 5 
 6         tail = new TailContext(this);
 7         head = new HeadContext(this);
 8 
 9         head.next = tail;
10         tail.prev = head;
11     }

 

     至此,完成了上面initAndRegister方法中的第一個功能:channel的實例化。此時NioServerSocketChannel的幾個父類屬性快照圖如下所示:

 

2、init(channel)方法

    init(channel)方法位於ServerBootstrap中(因為這裡是通過ServerBootstrap過來的,如果是通過Bootstrap進入的這裏則調用的就是Bootstrap中的init方法),主要功能如下註釋所示。本質都是針對channel進行初始化,初始化channel中的option、attr和pipeline。

 1 void init(Channel channel) throws Exception {
 2         // 1、獲取AbstractBootstrap中的options屬性,與channel進行關聯
 3         final Map<ChannelOption<?>, Object> options = options0();
 4         synchronized (options) {
 5             setChannelOptions(channel, options, logger);
 6         }
 7         // 2、獲取AbstractBootstrap中的attr屬性,與channel關聯起來
 8         final Map<AttributeKey<?>, Object> attrs = attrs0();
 9         synchronized (attrs) {
10             for (Entry<AttributeKey<?>, Object> e: attrs.entrySet()) {
11                 @SuppressWarnings("unchecked")
12                 AttributeKey<Object> key = (AttributeKey<Object>) e.getKey();
13                 channel.attr(key).set(e.getValue());
14             }
15         }
16         // 3、獲取pipeline,並將一個匿名handler對象添加進去,重要***
17         ChannelPipeline p = channel.pipeline();
18         final EventLoopGroup currentChildGroup = childGroup;
19         final ChannelHandler currentChildHandler = childHandler;
20         final Entry<ChannelOption<?>, Object>[] currentChildOptions;
21         final Entry<AttributeKey<?>, Object>[] currentChildAttrs;
22         synchronized (childOptions) {
23             currentChildOptions = childOptions.entrySet().toArray(newOptionArray(0));
24         }
25         synchronized (childAttrs) {
26             currentChildAttrs = childAttrs.entrySet().toArray(newAttrArray(0));
27         }
28         p.addLast(new ChannelInitializer<Channel>() {
29             @Override
30             public void initChannel(final Channel ch) throws Exception {
31                 final ChannelPipeline pipeline = ch.pipeline();
32                 ChannelHandler handler = config.handler();
33                 if (handler != null) {
34                     pipeline.addLast(handler);
35                 }
36 
37                 ch.eventLoop().execute(new Runnable() {
38                     @Override
39                     public void run() {
40                         pipeline.addLast(new ServerBootstrapAcceptor(
41                                 ch, currentChildGroup, currentChildHandler, currentChildOptions, currentChildAttrs));
42                     }
43                 });
44             }
45         });
46     }

    1跟2的功能都比較容易理解,功能3是init的核心,雖然代碼不少但很容易理解,它就是往channel中的pipeline里添加了一個匿名handler對象,其initChannel方法只有在有客戶端連接接入時才會調用,initChannel方法的功能是什麼呢?可以看到,它就是往入參channel中的eventLoop里添加了一個任務,這個任務的功能就是往pipeline中再添加一個handler,最後添加的這個handler就不是匿名的了,它是ServerBootstrapAcceptor對象。因為這裏的initChannel方法和後面的run方法都是有客戶端接入時才會調用的,所以這裏只是提一下,後面會詳述。至此完成init方法,下面進入register。

3、config().group().register(channel)方法

 3.1)、config().group()方法

    由前面可以知道,config().group().register(channel)這行代碼位於AbstractBootstrap類中的initAndRegister方法中,但由於當前對象是ServerBootstrap,故此處config()方法實際調用的都是ServerBootstrap中重寫的方法,得到了ServerBootstrapConfig。

    ServerBootstrapConfig的group方法如下,調用的是它的父類AbstractBootstrapConfig中的方法。通過類名就能知道,ServerBootstrapConfig中的方法是獲取ServerBootstrap中的屬性,而AbstractBootstrapConfig中的方法是獲取AbstractBootstrap中的屬性,兩兩對應。故此處獲取的EventLoopGroup就是AbstractBootstrap中存放的group,即文章開頭demo中的boss對象。

1 public final EventLoopGroup group() {
2         return bootstrap.group();
3     }

    獲取到了名叫boss的這個NioEventLoopGroup對象,下面追蹤NioEventLoopGroup.register(channel)方法

3.2)、 NioEventLoopGroup.register(channel)方法

    該方法是對之前初始化屬性的應用,需結合NioEventLoopGroup的初始化流程看,詳見【Netty源碼學習系列之2-NioEventLoopGroup的初始化】(鏈接【https://www.cnblogs.com/zzq6032010/p/12872989.html】)一文,此處就不贅述了,下面把該類的繼承類圖粘貼出來,以便有個整體認識。

 

3.2.1)、next()方法 

    下面的register方法位於MultithreadEventLoopGroup類中,是NioEventLoopGroup的直接父類,如下:

1 public ChannelFuture register(Channel channel) {
2         return next().register(channel);
3     }

    next方法如下,調用了父類的next方法,下面的就是父類MultithreadEventExecutorGroup中的next實現,可以看到調用的是chooser的next方法。通過初始化流程可知,此處boss的線程數是1,是2的n次方,所以chooser就是PowerOfTwoEventExecutorChooser,通過next方法從EventExecutor[]中選擇一個對象。需要注意的是chooser.next()通過輪詢的方式選擇的對象。

1 public EventLoop next() {
2         return (EventLoop) super.next();
3     }
1 public EventExecutor next() {
2         return chooser.next();
3     }

3.2.2)、NioEventLoop.register方法

    next之後是register方法,中間將NioServerSocketChannel和當前的NioEventLoop封裝成一個DefaultChannelPromise對象往下傳遞,在下面第二個register方法中可以看到,實際上調用的是NioServerSocketChannel中的unsafe屬性的register方法。

1 public ChannelFuture register(Channel channel) {
2         return register(new DefaultChannelPromise(channel, this));
3     }
1 public ChannelFuture register(final ChannelPromise promise) {
2         ObjectUtil.checkNotNull(promise, "promise");
3         promise.channel().unsafe().register(this, promise);
4         return promise;
5     }

3.2.3)、NioMessageUnsafe的register方法

    通過本文第一部分中第1步中的1.3)可以知道,NioServerSocketChannel中的unsafe是NioMessageUnsafe對象,下面繼續追蹤其register方法:

 1 public final void register(EventLoop eventLoop, final ChannelPromise promise) {
 2             if (eventLoop == null) {// 判斷非空
 3                 throw new NullPointerException("eventLoop");
 4             }
 5             if (isRegistered()) {// 判斷是否註冊
 6                 promise.setFailure(new IllegalStateException("registered to an event loop already"));
 7                 return;
 8             }
 9             if (!isCompatible(eventLoop)) {// 判斷eventLoop類型是否匹配
10                 promise.setFailure(
11                         new IllegalStateException("incompatible event loop type: " + eventLoop.getClass().getName()));
12                 return;
13             }
14        // 完成eventLoop屬性的賦值
15             AbstractChannel.this.eventLoop = eventLoop;
16             // 判斷eventLoop中的Reactor線程是不是當前線程 ***重要1
17             if (eventLoop.inEventLoop()) {
18                 register0(promise); // 進行註冊
19             } else {
20                 try {// 不是當前線程則將register0任務放入eventLoop隊列中讓Reactor線程執行(如果Reactor線程未初始化還要將其初始化) ***重要2
21                     eventLoop.execute(new Runnable() {
22                         @Override
23                         public void run() {
24                             register0(promise);// 註冊邏輯 ***重要3
25                         }
26                     });
27                 } catch (Throwable t) {
28                     // 省略異常處理
29                 }
30             }
31         }

    該方法位於io.netty.channel.AbstractChannel.AbstractUnsafe中(它是NioMessageUnsafe的父類),根據註釋能了解每一步做了什麼,但如果要理解代碼邏輯意圖則需要結合netty的串行無鎖化(串行無鎖化參見博主的netty系列第一篇文章https://www.cnblogs.com/zzq6032010/p/12872993.html)。它實際就是讓每一個NioEventLoop對象的thread屬性記錄一條線程,用來循環執行NioEventLoop的run方法,後續這個channel上的所有事件都由這一條線程來執行,如果當前線程不是Reactor線程,則會將任務放入隊列中,Reactor線程會不斷從隊列中獲取任務執行。這樣以來,所有事件都由一條線程順序處理,線程安全,也就不需要加鎖了。

    說完整體思路,再來結合代碼看看。上述代碼中標識【***重要1】的地方就是通過inEventLoop方法判斷eventLoop中的thread屬性記錄的線程是不是當前線程:

    先調到父類AbstractEventExecutor中,獲取了當前線程:

1 public boolean inEventLoop() {
2         return inEventLoop(Thread.currentThread());
3     }

    然後調到SingleThreadEventExecutor類中的方法,如下,比對thread與當前線程是否是同一個:

1 public boolean inEventLoop(Thread thread) {
2         return thread == this.thread;
3     }

    此時thread未初始化,所以肯定返回false,則進入【***重點2】的邏輯,將register放入run方法中封裝成一個Runnable任務,然後執行execute方法,如下,該方法位於SingleThreadEventExecutor中:

 1 public void execute(Runnable task) {
 2         if (task == null) {
 3             throw new NullPointerException("task");
 4         }
 5 
 6         boolean inEventLoop = inEventLoop();
 7         addTask(task); //將任務放入隊列中 ***重要a
 8         if (!inEventLoop) {
 9             startThread(); //判斷當前線程不是thread線程,則調用該方法 ***重要b
10             if (isShutdown()) {
11                 boolean reject = false;
12                 try {
13                     if (removeTask(task)) {
14                         reject = true;
15                     }
16                 } catch (UnsupportedOperationException e) {
17                     // 省略註釋
18                 }
19                 if (reject) {
20                     reject();
21                 }
22             }
23         }
24 
25         if (!addTaskWakesUp && wakesUpForTask(task)) {
26             wakeup(inEventLoop);
27         }
28     }

    有兩個重要的邏輯,已經在上面代碼中標出,先看看【***重要a】,如下,可見最終就是往SingleThreadEventExecutor的taskQueue隊列中添加了一個任務,如果添加失敗則調reject方法執行拒絕策略,通過前文分析可以知道,此處的拒絕策略就是直接拋錯。

1 protected void addTask(Runnable task) {
2         if (task == null) {
3             throw new NullPointerException("task");
4         }
5         if (!offerTask(task)) {
6             reject(task);
7         }
8     }
1 final boolean offerTask(Runnable task) {
2         if (isShutdown()) {
3             reject();
4         }
5         return taskQueue.offer(task);
6     }

    然後在看【***重要b】,如下,該方法雖然叫startThread,但內部有控制,不能無腦開啟線程,因為調這個方法的時候會有兩種情況:1).thread變量為空;2).thread不為空且不是當前線程。第一種情況需要開啟新的線程,但第二種情況就不能直接創建線程了。所以看下面代碼可以發現,它內部通過CAS+volatile(state屬性加了volatile修飾)實現的開啟線程的原子控制,保證多線程情況下也只會有一個線程進入doStartThread()方法。

 1 private void startThread() {
 2         if (state == ST_NOT_STARTED) {
 3             if (STATE_UPDATER.compareAndSet(this, ST_NOT_STARTED, ST_STARTED)) {
 4                 boolean success = false;
 5                 try {
 6                     doStartThread();
 7                     success = true;
 8                 } finally {
 9                     if (!success) {
10                         STATE_UPDATER.compareAndSet(this, ST_STARTED, ST_NOT_STARTED);
11                     }
12                 }
13             }
14         }
15     }

    繼續往下看一下doStartThread()的方法邏輯:

 1 private void doStartThread() {
 2         assert thread == null;
 3         executor.execute(new Runnable() { //此處的executor內部執行的就是ThreadPerTaskExecutor的execute邏輯,創建一個新線程運行下面的run方法
 4             @Override
 5             public void run() {
 6                 thread = Thread.currentThread(); //將Reactor線程記錄到thread變量中,保證一個NioEventLoop只有一個主線程在運行
 7                 if (interrupted) {
 8                     thread.interrupt();
 9                 }
10 
11                 boolean success = false;
12                 updateLastExecutionTime();
13                 try {
14                     SingleThreadEventExecutor.this.run(); //調用當前對象的run方法,該run方法就是Reactor線程的核心邏輯方法,後面會重點研究
15                     success = true;
16                 } catch (Throwable t) {
17                     logger.warn("Unexpected exception from an event executor: ", t);
18                 } finally {
19                    // 省略無關邏輯
20                 }
21             }
22         });
23     }

    可以看到,在上面的方法中完成了Reactor線程thread的賦值和核心邏輯NioEventLoop中run方法的啟動。這個run方法啟動后,第一步做的事情是什麼?讓我們往前回溯,回到3.2.3),當然是執行當初封裝了 register0方法的那個run方法的任務,即執行register0方法,下面填之前埋得坑,對【***重要3】進行追蹤:

 1 private void register0(ChannelPromise promise) {
 2             try {
 3                 // 省略判斷邏輯
 4                 boolean firstRegistration = neverRegistered;
 5                 doRegister();// 執行註冊邏輯
 6                 neverRegistered = false;
 7                 registered = true;
 8                 pipeline.invokeHandlerAddedIfNeeded();// 調用pipeline的邏輯
 9 
10                 safeSetSuccess(promise);
11                 pipeline.fireChannelRegistered();
12                 // 省略無關邏輯
13             } catch (Throwable t) {
14                 // 省略異常處理
15             }
16         }

    doRegister()方法的實現在AbstractNioChannel中,如下,就是完成了nio中的註冊,將nio的ServerSocketChannel註冊到selector上:

 1 protected void doRegister() throws Exception {
 2         boolean selected = false;
 3         for (;;) {
 4             try {
 5                 selectionKey = javaChannel().register(eventLoop().unwrappedSelector(), 0, this);
 6                 return;
 7             } catch (CancelledKeyException e) {
 8                // 省略異常處理
 9             }
10         }
11     }

    再看pipeline.invokeHandlerAddedIfNeeded()方法,該方法調用鏈路比較長,此處就不詳細粘貼了,只是說一下流程。回顧下上面第二部分的第2步,在裏面最後addLast了一個匿名的內部對象,重寫了initChannel方法,此處通過pipeline.invokeHandlerAddedIfNeeded()方法就會調用到這個匿名對象的initChannel方法(只有第一次註冊時才會調),該方法往pipeline中又添加了一個ServerBootstrapAcceptor對象。執行完方法后,netty會在finally中將之前那個匿名內部對象給remove掉,這時pipeline中的handler如下所示:

 

     至此,算是基本完成了initAndRegister方法的邏輯,當然限於篇幅(本篇已經夠長了),其中還有很多細節性的處理未提及。

 

三、AbstractBootstrap的doBind0方法

     doBind0方法邏輯如下所示,new了一個Runnable任務交給Reactor線程執行,execute執行過程已經分析過了,此處不再贅述,集中下所剩無幾的精力看下run方法中的bind邏輯。

 1 private static void doBind0(
 2             final ChannelFuture regFuture, final Channel channel,
 3             final SocketAddress localAddress, final ChannelPromise promise) {
 4 
 5         channel.eventLoop().execute(new Runnable() {
 6             @Override
 7             public void run() {
 8                 if (regFuture.isSuccess()) {
 9                     channel.bind(localAddress, promise).addListener(ChannelFutureListener.CLOSE_ON_FAILURE);
10                 } else {
11                     promise.setFailure(regFuture.cause());
12                 }
13             }
14         });
15     }

    channel.bind方法,如下:

1 public ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {
2         return pipeline.bind(localAddress, promise);
3     }

    調用了pipeline的bind方法:

1 public final ChannelFuture bind(SocketAddress localAddress, ChannelPromise promise) {
2         return tail.bind(localAddress, promise);
3     }

    tail.bind方法:

 1 public ChannelFuture bind(final SocketAddress localAddress, final ChannelPromise promise) {
 2         if (localAddress == null) {
 3             throw new NullPointerException("localAddress");
 4         }
 5         if (isNotValidPromise(promise, false)) {
 6             // cancelled
 7             return promise;
 8         }
 9         // 從tail開始往前,找到第一個outbond的handler,這時只有head滿足要求,故此處next是head
10         final AbstractChannelHandlerContext next = findContextOutbound(MASK_BIND);
11         EventExecutor executor = next.executor();
12         if (executor.inEventLoop()) {// 因為當前線程就是executor中的Reactor線程,所以直接進入invokeBind方法
13             next.invokeBind(localAddress, promise);
14         } else {
15             safeExecute(executor, new Runnable() {
16                 @Override
17                 public void run() {
18                     next.invokeBind(localAddress, promise);
19                 }
20             }, promise, null);
21         }
22         return promise;
23     }

    下面進入head.invokeBind方法:

 1 private void invokeBind(SocketAddress localAddress, ChannelPromise promise) {
 2         if (invokeHandler()) {
 3             try {
 4                 ((ChannelOutboundHandler) handler()).bind(this, localAddress, promise);
 5             } catch (Throwable t) {
 6                 notifyOutboundHandlerException(t, promise);
 7             }
 8         } else {
 9             bind(localAddress, promise);
10         }
11     }

    核心邏輯就是handler.bind方法,繼續追蹤:

1 public void bind(
2                 ChannelHandlerContext ctx, SocketAddress localAddress, ChannelPromise promise) {
3             unsafe.bind(localAddress, promise);
4         }

    此處的unsafe是NioMessageUnsafe,繼續追蹤會看到在bind方法中又調用了NioServerSocketChannel中的doBind方法,最終在這裏完成了nio原生ServerSocketChannel和address的綁定:

1 protected void doBind(SocketAddress localAddress) throws Exception {
2         if (PlatformDependent.javaVersion() >= 7) {
3             javaChannel().bind(localAddress, config.getBacklog());
4         } else {
5             javaChannel().socket().bind(localAddress, config.getBacklog());
6         }
7     }

    至此,ServerBootstrap的bind方法完成。

 

小結

    本文從頭到尾追溯了ServerBootstrap中bind方法的邏輯,將前面netty系列中的二、三兩篇初始化給串聯了起來,是承上啟下的一個位置。後面的netty系列將圍繞本文中啟動的NioEventLoop.run方法展開,可以這麼說,本文跟前面的三篇只是為run方法的出現做的一個鋪墊,run方法才是核心功能的邏輯所在。

    本文斷斷續續更新了一周,今天才完成,也沒想到會這麼長,就這樣吧,後面繼續netty run方法的學習。

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

【其他文章推薦】

※回頭車貨運收費標準

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

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

※推薦評價好的iphone維修中心

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

「福島套餐」:奧運選手的被曝風險 民團仍訴求停辦東奧(上)

3{icon} {views}

文:宋瑞文(媽媽監督核電廠聯盟特約撰述)

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

※回頭車貨運收費標準

南極地區首次發現青蛙化石碎片

2{icon} {views}

摘錄自2020年4月27日俄羅斯衛星通訊社報導

根據發表在《Scientific Reports》期刊的研究報告,科研人員在南極半島北端的西莫爾島發現了數塊青蛙的頭骨和部分髖骨化石碎片,這種古老的生物是南美地區現代頭盔蛙科的近親。

這一的發現讓科學家對南極大陸的古代氣候有了新的認識。這些化石碎片距今約4000萬年,頭骨形狀可以看出這隻青蛙屬於頭盔蛙科。頭盔蛙科現生種生活在南美安第斯山脈中部的溫暖潮濕山谷中。這表明,至少4000萬年前,南極洲地區也是類似的氣候。

這一發現改變了科學家對南極大陸氣候變化的認識。大多數科學家認為,大約4000萬年前,南極洲與澳洲大陸分離後迅速被冰層覆蓋。但是一些證據表明,在南極大陸與南半球其他現代大陸完全分離前,南極洲冰蓋就已經開始形成。

生態保育
物種保育
生物多樣性
國際新聞
南極
古生物學
化石
青蛙
兩棲類
南極

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※回頭車貨運收費標準

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

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

※推薦評價好的iphone維修中心

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

動物、人與環境健康一體的紓困方案 聯合國科學家提三點呼籲

2{icon} {views}

整理:鄒敏惠(環境資訊中心記者)

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

※台北網頁設計公司全省服務真心推薦

※想知道最厲害的網頁設計公司"嚨底家"!

※推薦評價好的iphone維修中心

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

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

淺談鏈接器

1{icon} {views}

目錄

  • 編譯過程簡介
  • 什麼是鏈接器?
  • 鏈接器可操作的元素:目標文件
  • 符號表(Symbol table)
    • 符號決議
  • 庫與可執行文件
    • 靜態庫
    • 動態庫
  • 參考
  • 微信公共號

編譯過程簡介

C語言的編譯過程由五個階段組成:

  • 步驟1:預處理:主要是處理以#開頭的語句,主要工作如下:1)將#include包含的頭文件直接拷貝到.c文件中;2)將#define定義的宏進行替換;3)處理條件編譯指令#ifdef;4)將代碼中的註釋刪除;5)添加行號和文件標示,這樣的在調試和編譯出錯的時候才知道是是哪個文件的哪一行 ;6)保留#pragma編譯器指令,因為編譯器需要使用它們。
gcc -E helloworld.c -o helloworld_pre.c
  • 步驟2: 編譯:將C語言翻譯成彙編,主要工作如下:1)詞法分析;2)語法分析;3)語義分析 4)優化後生成相應的彙編;
gcc -S helloworld.c -o helloworld.s
  • 步驟3: 彙編:將上一步的彙編代碼轉換成機器碼(machine code),這一步產生的文件叫做目標文件;
gcc -c helloworld.c -o helloworld.o
  • 步驟4:鏈接:將多個目標文以及所需的庫文件(.so等)鏈接成最終的可執行文件(executable file)。
gcc helloworld.c -o helloworld

什麼是鏈接器?

鏈接器是一個將編譯器產生的目標文件打包成可執行文件或者庫文件或者目標文件的程序。

鏈接器的作用有點類似於我們經常使用的壓縮軟WinRAR(Linux下是tar),壓縮軟件將一堆文件打包壓縮成一個壓縮文件,而鏈接器和壓縮軟件的區別在於鏈接器是將多個目標文件打包成一個文件而不進行壓縮。

寫C或者C++的u同學經常遇到這樣一個錯誤:

undefined reference to function ABC.

鏈接器可操作的元素:目標文件

鏈接器可操作的最小元素是一個簡單的目標文件
從廣義上來講,目標文件與可執行文件的格式幾乎是一模一樣的,在Linux下,我們把它們統稱為ELF文件。

ELF文件標準裏面把系統中採用ELF格式的文件歸為以下四類:

  • 可重定位文件(Relocatable File):Linux的.o文件,這類文件包含了代碼和數據,可以被用來鏈接成可執行文件或共享目標文件,靜態鏈接庫也歸屬於這一類;

  • 可執行文件(Executable File):比如bin/bash文件,這類文件包含了可以直接執行的程序,它的代表就是ELF文件,他們一般都沒有擴展名;

  • 共享目標文件(shared Object File): 比如Linux的.so文件,這種文件包含了代碼和數據,可以在以下兩種情況下使用,一種是鏈接器可以直接使用這種文件跟其他的可重定位文件和共享目標文件鏈接,產生新的目標文件。第二種是動態鏈接器可以將幾個這樣的共享目標文件與可執行文件結合,作為進程映射的一部分來運行。

  • 核心轉儲文件(Core Dump File): Linux下面的core dump,當進程意外終止時,系統可以將該進程的地址空間的內容及終止時的一些其他信息轉儲到核心轉儲文件中。

符號表(Symbol table)

編譯器在遇到外部定義的全局變量或者函數時只要能在當前文件找到其聲明,編譯器就認為編譯正確。而尋找使用變量定義的這項任務就被留給了鏈接器。鏈接器的其中一項任務就是要確定所使用的變量要有其唯一的定義。雖然編譯器給鏈接器留了一項任務,但為了讓鏈接器工作的輕鬆一點編譯器還是多做了一點工作的,這部分工作就是符號表(Symbol table)。

符號表中保存的信息有兩個部分:

  • 該目標文件中引用的全局變量以及函數;
  • 該目標文件中定義的全局變量以及函數。

編譯器在編譯過程中每次遇到一個全局變量或者函數名都會在符號表中添加一項,最終編譯器會統計一張符號表。

假設C語言源碼如下:

// 定義未初始化的全局變量
int g_x_uninit;

// 定義初始化的全局變量
int g_x_init = 1;

// 定義未初始化的全局私有變量,只能在當前文件中使用
static int g_y_uninit;

// 定義初始化的全局私有變量
static int g_y_init = 2;

// 聲明全局變量,該變量的定義在其它文件
extern int g_z;

// 函數聲明,該函數的定義在其它文件
int fn_a(int x, int y);

// 私有函數定義,該函數只能在當前文件中使用
static int fn_b(int x)
{
    return x + 1;
}

// 函數定義
int fn_c(int local_x)
{
    int local_y_uninit;
    int local_y_init = 3;
    // 對全局變量,局部變量以及函數的使用
    g_x_uninit = fn_a(local_x, g_x_init);
    g_y_uninit = fn_a(local_x, local_y_init);
    local_y_uninit += fn_b(g_z);
    return (g_y_uninit + local_y_uninit);
}

編譯器將為此文件統計出如下一張符號表:

名字 類型 是否可被外部引用 區域
g_z 引用,未定義
fn_a 引用,未定義
fn_b 定義 代碼段
fn_c 定義 代碼段
g_x_init 定義 數據段
g_y_uninit 定義 數據段
g_x_uninit 定義 數據段
g_y_init 定義 數據段

g_z以及fn_a是未定義的,因為在當前文件中,這兩個變量僅僅是聲明,編譯器並沒有找到其定義。剩餘的變量編譯器都可以在當前文件中找到其定義。

本質上整個符號表主要表達兩件事:1)我能提供給其它文件使用的符號; 2)我需要其它文件提供給我使用的符號。

目標文件
數據段
代碼段
符號表

符號決議

有了符號表,鏈接器就可以進行符號決議了。如圖所示,假設鏈接器需要鏈接三個目標文件,如下:

鏈接器會依次掃描每一個給定的目標文件,同時鏈接器還維護了兩個集合,一個是已定義符號集合D,另一個是未定義符合集合U,下面是鏈接器進行符合決議的過程:

  • 對於當前目標文件,查找其符號表,並將已定義的符號並添加到已定義符號集合D中。
  • 對於當前目標文件,查找其符號表,將每一個當前目標文件引用的符號與已定義符號集合D進行對比,如果該符號不在集合D中則將其添加到未定義符合集合U中。
  • 當所有文件都掃描完成后,如果為定義符號集合U不為空,則說明當前輸入的目標文件集合中有未定義錯誤,鏈接器報錯,整個編譯過程終止。

鏈接過程中,只要每個目標文件所引用變量都能在其它目標文件中找到唯一的定義,整個鏈接過程就是正確的。

若鏈接器在查找了所有目標文件的符號表后都沒有找到函數,因此鏈接器停止工作並報出錯誤undefined reference to function A

庫與可執行文件

鏈接器根據目標文件構建出庫(動態庫、靜態庫)或可執行文件。

給定目標文件以及鏈接選項,鏈接器可以生成兩種庫,分別是靜態庫以及動態庫,如下圖所示,給定同樣的目標文件,鏈接器可以生成兩種不同類型的庫。

靜態庫

靜態庫在Windows下是以.lib為後綴的文件,Linux下是以.a為後綴的文件。

靜態庫是鏈接器通過靜態鏈接將其和其它目標文件合併生成可執行文件的,而靜態庫只不過是將多個目標文件進行了打包,在鏈接時只取靜態庫中所用到的目標文件。

目標文件分為三段:代碼段、數據段、符號表,在靜態鏈接時可執行文件的生成過程如下圖所示:

可執行文件的特點如下:

  • 可執行文件和目標文件一樣,也是由代碼段和數據段組成。
  • 每個目標文件中的數據段都合併到了可執行文件的數據段,每個目標文件當中的代碼段都合併到了可執行文件的代碼段。
  • 目標文件當中的符號表並沒有合併到可執行文件當中,因為可執行文件不需要這些字段。

可執行文件和目標文件沒有什麼本質的不同,可執行文件區別於目標文件的地方在於,可執行文件有一個入口函數,這個函數也就是我們在C語言當中定義的main函數,main函數在執行過程中會用到所有可執行文件當中的代碼和數據。main函數是被操作系統調用。

動態庫

靜態庫在編譯鏈接期間就被打包copy到了可執行文件,也就是說靜態庫其實是在編譯期間(Compile time)鏈接使用的。
動態鏈接可以在兩種情況下被鏈接使用,分別是加載時動態鏈接(load-time dynamic linking)運行時動態鏈接 (run-time dynamic linking)

  • 加載時動態鏈接:在這裏我們只需要簡單的把加載理解為程序從磁盤複製到內存的過程,加載時動態鏈接就出現在這個過程。操作系統會查找可執行文件依賴的動態庫信息(主要是動態庫的名字以及存放路徑),找到該動態庫后就將該動態庫從磁盤搬到內存,並進行符號決議,如果這個過程沒有問題,那麼一切準備工作就緒,程序就可以開始執行了,如果找不到相應的動態庫或者符號決議失敗,那麼會有相應的錯誤信息報告為用戶,程序運行失敗。

  • 運行時動態鏈接:run-time dynamic linking 運行時動態鏈接則不需要在編譯鏈接時提供動態庫信息,也就是說,在可執行文件被啟動運行之前,可執行文件對所依賴的動態庫信息一無所知,只有當程序運行到需要調用動態庫所提供的代碼時才會啟動動態鏈接過程。

可以使用特定的API來運行時加載動態庫,在Windows下通過LoadLibrary或者LoadLibraryEx,在Linux下通過使用dlopen、dlsym、dlclose這樣一組函數在運行時鏈接動態庫。當這些API被調用后,同樣是首先去找這些動態庫,將其從磁盤copy到內存,然後查找程序依賴的函數是否在動態庫中定義。這些過程完成后動態庫中的代碼就可以被正常使用了。

在動態鏈接下,可執行文件當中會新增兩段,即dynamic段以及GOT(Global offset table)段,這兩段內容就是是我們之前所說的必要信息。

dynamic 段中保存了可執行文件依賴哪些動態庫,動態鏈接符號表的位置以及重定位表的位置等信息。
當加載可執行文件時,操作系統根據dynamic段中的信息即可找到使用的動態庫,從而完成動態鏈接

參考

  • C語言編譯的4大過程詳解
  • C語言編程透視
  • 徹底理解鏈接器:二,符號決議

微信公共號

NFVschool,關注最前沿的網絡技術。

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家公司費用怎麼算?

一次依賴注入不慎引發的一連串事故

3{icon} {views}

一次依賴注入不慎引發的一連串事故

起因和現象

偶爾會看到線上服務啟動的時候第一波流量進來之後,

遲遲沒有任何的響應,同時服務的監控檢查接口正常,

所以 K8S 集群認為服務正常,繼續放入流量。

查看日誌基本如下:


[2020-06-05T13:00:30.7080743+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test
[2020-06-05T13:00:30.7081525+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type
[2020-06-05T13:00:31.7074253+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR21" started.
[2020-06-05T13:00:31.7077051+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test/account-balance
[2020-06-05T13:00:31.7077942+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type
[2020-06-05T13:00:32.2103440+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR22" started.
[2020-06-05T13:00:32.2118432+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test/account-balance
[2020-06-05T13:00:32.2125894+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-ba'lan'ce does not match a supported file type
[2020-06-05T13:00:33.2223942+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR23" started.
[2020-06-05T13:00:33.2238736+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test/account-balance
[2020-06-05T13:00:33.2243808+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type
[2020-06-05T13:00:34.2177528+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR24" started.
[2020-06-05T13:00:34.2189073+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test/account-balance
[2020-06-05T13:00:34.2193483+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type
[2020-06-05T13:00:35.2169806+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR25" started.
[2020-06-05T13:00:35.2178259+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test/account-balance
[2020-06-05T13:00:35.2181055+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type
[2020-06-05T13:00:36.2183025+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR26" started.
[2020-06-05T13:00:36.2195050+00:00 Microsoft.AspNetCore.Hosting.Diagnostics INF] Request starting HTTP/1.0 GET http://172.16.2.52/v1/user/test/account-balance
[2020-06-05T13:00:36.2199702+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG] The request path /v1/user/test/account-balance does not match a supported file type
[2020-06-05T13:00:37.2373822+00:00 Microsoft.AspNetCore.Server.Kestrel DBG] Connection id "0HM09A1MAAR27" started.

引發的幾種後果

客戶端調用超時

經過了 30S 甚至更長時間后看到大量的數據庫連接被初始化,然後開始集中式返回。

此時可能對於客戶端調用來說這一批請求都是超時的,

嚴重影響用戶體驗和某些依賴於此的其他接口。

數據庫連接暴漲

因為同時進入大量數據庫查詢請求觸發數據庫 DbContextPool 大量創建,

連接數隨之暴漲,數據庫查詢性能急速下降,可能引發其他的應用問題。

引發服務“雪崩”效應,服務不可用

請求堆積的情況下,

health-check 接口響應異常,

導致 k8s 主動重啟服務,重啟後繼續上述情況,

不斷惡化最後導致服務不可用。

排查問題

數據庫的問題 ?

當然,首先懷疑的就是數據庫了。

存在性能瓶頸?慢查詢導致不響應?發布期間存在其他的異常?

這類的問題都意義排查起來了。

最後發現,

這種情況發生的時候,數據庫監控裏面一片祥和。

數據庫 IO、CPU、內存都正常,

連接數暴漲是這種情況發生的時候帶來的,

而不是連接數暴漲之後導致了此情況。

數據庫驅動或者 EF Core 框架的問題?

是的,

這個懷疑一直都存在於腦海中。

最終,

昨天帶着“被挨罵的情況”去問了下“Pomelo.EntityFrameworkCore.MySql”的作者。


春天的熊 18:34:08
柚子啊,我這邊的.NET Core服務剛起來,建立MySQL連接的時候好慢,然後同一批請求可能無法正常響應,這個有什麼好的解決思路嗎?

Yuko丶柚子 18:34:29
Min Pool Size = 200

Yuko丶柚子 18:34:32
放連接字符串里

春天的熊 18:34:53
這個字段支持了嗎?

Yuko丶柚子 18:35:07
一直都支持

春天的熊 18:35:56
等等,      public static IServiceCollection AddDbContextPool<TContext>([NotNullAttribute] this IServiceCollection serviceCollection, [NotNullAttribute] Action<DbContextOptionsBuilder> optionsAction, int poolSize = 128) where TContext : DbContext;

春天的熊 18:36:13
這裏不是默認最大的128么?

Yuko丶柚子 18:36:18
你這個pool size是dbcontext的

Yuko丶柚子 18:36:21
我說的是mysql連接字符串的

Yuko丶柚子 18:36:28
dbcontext的pool有什麼用

春天的熊 18:43:13
我問個討打的問題,dbcontext 是具體的鏈接實例,EF用的,Min Pool Size 指的是這一個實例上面的連接池嗎“?

Yuko丶柚子 18:44:07
你在說什麼。。。

Yuko丶柚子 18:45:58
放到mysql的連接字符串上

Yuko丶柚子 18:46:14
這樣第一次調用MySqlConnection的時候就會建立200個連接

春天的熊 18:46:56
默認是多少來的?100嗎?

Yuko丶柚子 18:48:33
0

Yuko丶柚子 18:48:40
max默認是100

Yuko丶柚子 18:52:50
DbContextPool要解決的問題你都沒搞清楚

春天的熊 18:53:23
DbContextPool要解決的是盡量不去重複創建DbContext

Yuko丶柚子 18:53:34
為什麼不要重複創建DbContext

春天的熊 18:53:50
因為每個DbContext創建的代價很高,而且很慢

Yuko丶柚子 18:54:01
創建DbContext有什麼代價

Yuko丶柚子 18:54:03
哪裡慢了

Yuko丶柚子 18:54:06
都是毫秒級的

Yuko丶柚子 18:54:20
他的代價不在於創建 而在於回收

Yuko丶柚子 18:54:25
DbContextPool要解決的問題是 因為DbContext屬於較大的對象,而且是頻繁被new,而且經常失去引用導致GC頻繁工作。

Yuko 大大說的情況感覺會是一個思路,

所以第一反應就是加了參數控制連接池。

不過,無果。

5 個實例,

有 3 個實例正常啟動,

2 個實例會重複“雪崩”效應,最終無法正常啟動。

這個嘗試操作重複了好多次,

根據文檔和 Yuko 大大指導繼續加了不少 MySQL 鏈接參數,

最後,

重新學習了一波鏈接參數的優化意義,

無果。

究竟數據庫驅動有沒有問題?

沒什麼好的思路了,

遠程到容器裏面 Debug 基本不太現實(重新打包 + 容器化打包 + k8s + 人肉和服務器垮大洋),

要不,試試把日誌登錄調節到 Debug 看看所有的行為?

{
  "Using": ["Serilog.Sinks.Console"],
  "MinimumLevel": {
    "Default": "Debug",
    "Override": {
      "Microsoft": "Debug"
    }
  },
  "WriteTo": [
    {
      "Name": "Console",
      "Args": {
        "outputTemplate": "[{Timestamp:o}  {SourceContext} {Level:u3}] {Message:lj}{NewLine}{Exception}"
      }
    }
  ]
}

當然,這個事情沒有直接在正常的生產環境執行。

這裡是使用新配置,重新起新實例來操作。

然後我們看到程序啟動的時候執行 EFMigration 的時候,

程序和整個數據庫交互的完整日誌。


[2020-06-05T12:59:56.4147202+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Opening connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.4159970+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Opened connection to database 'user_pool' on server 'a'li'yun'.
[2020-06-05T12:59:56.4161172+00:00 Microsoft.EntityFrameworkCore.Database.Command DBG] Executing DbCommand [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='user_pool' AND TABLE_NAME='__EFMigrationsHistory';
[2020-06-05T12:59:56.4170776+00:00 Microsoft.EntityFrameworkCore.Database.Command INF] Executed DbCommand (1ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='user_pool' AND TABLE_NAME='__EFMigrationsHistory';
[2020-06-05T12:59:56.4171630+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Closing connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.4172458+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Closed connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.4385345+00:00 Microsoft.EntityFrameworkCore.Database.Command DBG] Creating DbCommand for 'ExecuteReader'.
[2020-06-05T12:59:56.4386201+00:00 Microsoft.EntityFrameworkCore.Database.Command DBG] Created DbCommand for 'ExecuteReader' (0ms).
[2020-06-05T12:59:56.4386763+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Opening connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.4400143+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Opened connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.4404529+00:00 Microsoft.EntityFrameworkCore.Database.Command DBG] Executing DbCommand [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT `MigrationId`, `ProductVersion`
FROM `__EFMigrationsHistory`
ORDER BY `MigrationId`;
[2020-06-05T12:59:56.4422387+00:00 Microsoft.EntityFrameworkCore.Database.Command INF] Executed DbCommand (2ms) [Parameters=[], CommandType='Text', CommandTimeout='30']
SELECT `MigrationId`, `ProductVersion`
FROM `__EFMigrationsHistory`
ORDER BY `MigrationId`;
[2020-06-05T12:59:56.4446400+00:00 Microsoft.EntityFrameworkCore.Database.Command DBG] A data reader was disposed.
[2020-06-05T12:59:56.4447422+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Closing connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.4447975+00:00 Microsoft.EntityFrameworkCore.Database.Connection DBG] Closed connection to database 'user_pool' on server 'aliyun-rds'.
[2020-06-05T12:59:56.5170419+00:00 Microsoft.EntityFrameworkCore.Migrations INF] No migrations were applied. The database is already up to date.

看到這裏的時候,由於發現我們之前對 DbContext 和 DbConnection 的理解不太好,

想搞清楚究竟是不 db connection 創建的時候有哪些行為,

於是我們找到了 dotnet/efcore Github 的源碼開始拜讀,

PS: 源碼真香,能看源碼真好。

嘗試通過“Opening connection”找到日誌的場景。

想了解這個日誌輸出的時候代碼在做什麼樣的事情,可能同時會有哪些行為。

在考慮是不是其他的一些行為導致了上面的服務問題?

最終在RelationalConnection.cs確認上面這些數據庫相關日誌肯定是會輸出的,不存在其他的異常行為。

PS:不用細看,我們認真瀏覽了代碼之後確認 DbContext 正常初始化,

        /// <summary>
        ///     Asynchronously opens the connection to the database.
        /// </summary>
        /// <param name="errorsExpected"> Indicate if the connection errors are expected and should be logged as debug message. </param>
        /// <param name="cancellationToken">
        ///     A <see cref="CancellationToken" /> to observe while waiting for the task to complete.
        /// </param>
        /// <returns>
        ///     A task that represents the asynchronous operation, with a value of <see langword="true"/> if the connection
        ///     was actually opened.
        /// </returns>
        public virtual async Task<bool> OpenAsync(CancellationToken cancellationToken, bool errorsExpected = false)
        {
            if (DbConnection.State == ConnectionState.Broken)
            {
                await DbConnection.CloseAsync().ConfigureAwait(false);
            }

            var wasOpened = false;
            if (DbConnection.State != ConnectionState.Open)
            {
                if (CurrentTransaction != null)
                {
                    await CurrentTransaction.DisposeAsync().ConfigureAwait(false);
                }

                ClearTransactions(clearAmbient: false);
                await OpenDbConnectionAsync(errorsExpected, cancellationToken).ConfigureAwait(false);
                wasOpened = true;
            }

            _openedCount++;

            HandleAmbientTransactions();

            return wasOpened;
        }


        private async Task OpenDbConnectionAsync(bool errorsExpected, CancellationToken cancellationToken)
        {
            var startTime = DateTimeOffset.UtcNow;
            var stopwatch = Stopwatch.StartNew();

            // 日誌輸出在這裏
            var interceptionResult
                = await Dependencies.ConnectionLogger.ConnectionOpeningAsync(this, startTime, cancellationToken)
                    .ConfigureAwait(false);

            try
            {
                if (!interceptionResult.IsSuppressed)
                {
                    await DbConnection.OpenAsync(cancellationToken).ConfigureAwait(false);
                }
                // 日誌輸出在這裏
                await Dependencies.ConnectionLogger.ConnectionOpenedAsync(this, startTime, stopwatch.Elapsed, cancellationToken)
                    .ConfigureAwait(false);
            }
            catch (Exception e)
            {
                await Dependencies.ConnectionLogger.ConnectionErrorAsync(
                    this,
                    e,
                    startTime,
                    stopwatch.Elapsed,
                    errorsExpected,
                    cancellationToken)
                    .ConfigureAwait(false);

                throw;
            }

            if (_openedCount == 0)
            {
                _openedInternally = true;
            }
        }

當然,我們同時也去看了一眼 MySqlConnector的源碼,

確認它自身是維護了數據庫連接池的。到這裏基本確認不會是數據庫驅動導致的上述問題。

某種猜測

肯定是有什麼奇怪的行為阻塞了當前服務進程,

導致數據庫連接的日誌也沒有輸出。

鎖? 異步等同步?資源初始化問題?

周五晚上查到了這裏已經十一點了,

於是先下班回家休息了。

於是,

周六練完車之後 Call 了一下小夥伴,

又雙雙開始了愉快的 Debug。

插曲

小夥伴海林回公司前發了個朋友圈。

“ 咋們繼續昨天的 bug,

特此立 flag:修不好直播吃 bug

反正不是你死就是我亡…”

我調侃評論說:

你等下,我打包下代碼去樓下打印出來待會當晚飯

開始鎖定問題

中間件導致的嗎?

[2020-06-05T13:00:35.2181055+00:00 Microsoft.AspNetCore.StaticFiles.StaticFileMiddleware DBG]

The request path /v1/user/test/account-balance does not match a supported file type

我們對着這個日誌思考了一會人生,

然後把引用此中間件的代碼註釋掉了,

不過,無果。

自定義 filters 導致的嗎?


[2020-06-05T13:01:05.3126001+00:00 Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker DBG] Execution plan of exception filters (in the following order): ["None"]
[2020-06-05T13:01:05.3126391+00:00 Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker DBG] Execution plan of result filters (in the following order): ["Microsoft.AspNetCore.Mvc.ViewFeatures.Filters.SaveTempDataFilter", "XXX.Filters.HTTPHeaderAttribute (Order: 0)"]
[2020-06-05T13:01:05.3072206+00:00 Microsoft.AspNetCore.Mvc.Infrastructure.ControllerActionInvoker DBG] Execution plan of authorization filters (in the following order): ["None"]

看到這個日誌我們考慮了一下,

是不是因為 filters 導致了問題。

畢竟在 HTTPHeaderAttribute 我們還還做了 ThreadLocal<Dictionary<string, string>> CurrentXHeaders

這裏懷疑是不是我們的實現存在鎖機制導致“假死問題”。

嘗試去掉。

不過,

無果。

嘗試使用 ptrace

沒什麼很好的頭緒了,要不上一下 ptrace 之類的工具跟一下系統調用?

最早在去年就嘗試過使用 ptrace 抓進程數據看系統調用,

後來升級到.NET Core3.0 之後,官方基於 Events + LTTng 之類的東西做了 dotnet-trace 工具,

官網說明:dotnet-trace performance analysis utility

改一下打包扔上去做一個數據收集看看。


FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build-env
WORKDIR /app

# copy csproj and restore as distinct layers
COPY src/*.csproj ./
RUN dotnet restore

COPY . ./

# copy everything else and build
RUN dotnet publish src -c Release -o /app/out


# build runtime image
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1

# debug
# Install .NET Core SDK
RUN dotnet_sdk_version=3.1.100 \
    && curl -SL --output dotnet.tar.gz https://dotnetcli.azureedge.net/dotnet/Sdk/$dotnet_sdk_version/dotnet-sdk-$dotnet_sdk_version-linux-x64.tar.gz \
    && dotnet_sha512='5217ae1441089a71103694be8dd5bb3437680f00e263ad28317665d819a92338a27466e7d7a2b1f6b74367dd314128db345fa8fff6e90d0c966dea7a9a43bd21' \
    && echo "$dotnet_sha512 dotnet.tar.gz" | sha512sum -c - \
    && rm -rf /usr/share/dotnet \
    && rm -rf /usr/bin/dotnet \
    && mkdir -p /usr/share/dotnet \
    && tar -ozxf dotnet.tar.gz -C /usr/share/dotnet \
    && rm dotnet.tar.gz \
    && ln -s /usr/share/dotnet/dotnet /usr/bin/dotnet \
    # Trigger first run experience by running arbitrary cmd
    && dotnet help
RUN dotnet tool install --global dotnet-trace
RUN dotnet tool install -g dotnet-dump
RUN dotnet tool install --global dotnet-counters
ENV PATH="$PATH:/root/.dotnet/tools"

# end debug

WORKDIR /app
COPY --from=build-env /app/out .
ENTRYPOINT ["dotnet", "Your-APP.dll"]


更新發布,等待服務正常啟動之後,

使用 ab -c 300 -n 3000 ‘http://172.16.2.52/v1/user/test/account-balance’ 模擬 300 個用戶同時請求,

使得程序進入上述的“假死狀態”。

接着立即進入容器,執行’dotnet-trace collect -p 1′ 開始收集日誌。

最後拿到了一份大概 13M trace.nettrace 數據, 這個文件是 PerView 支持的格式,

在 MacOS 或者 Linux 上無法使用。

好在 dotnet-trace convert 可以將 trace.nettrace 轉換成 speedscope/chromium 兩種格式。

speedscope/chromium

  • speedscope:A fast, interactive web-based viewer for performance profiles.

  • chrome-devtools evaluate-performance

  • 全新 Chrome Devtool Performance 使用指南

$dotnet-trace convert 20200606-1753-trace.nettrace.txt  --format Speedscope
$dotnet-trace convert 20200606-1753-trace.nettrace.txt --format chromium
$speedscope 20200606-1753-trace.nettrace.speedscope.json

然後,炸雞了。

  Downloads speedscope 20200606-1625.trace.speedscope.json
Error: Cannot create a string longer than 0x3fffffe7 characters
    at Object.slice (buffer.js:652:37)
    at Buffer.toString (buffer.js:800:14)
    at main (/home/liguobao/.nvm/versions/node/v12.16.2/lib/node_modules/speedscope/bin/cli.js:69:39)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)

Usage: speedscope [filepath]

If invoked with no arguments, will open a local copy of speedscope in your default browser.
Once open, you can browse for a profile to import.

If - is used as the filepath, will read from stdin instead.

  cat /path/to/profile | speedscope -

哦, Buffer.toString 炸雞了。

看一眼 20200606-1625.trace.speedscope.json 多大?

900M。

牛逼。

那換 Chrome performance 看看。

手動裝載一下 20200606-1753-trace.nettrace.chromium.json 看看。

等下,20200606-1753-trace.nettrace.chromium.json 這貨多大?

哦,4G。應該沒事,Intel NUC 主機內存空閑 20G,吃掉 4G 完全是沒有問題的。

看着進度條加載,看着內存漲起來,

然後…Chrome 控制台奔潰。再見再見,原來大家彼此完全沒有信任了。

唉,再來一次,把文件控制在 5M 左右看看。

最後,把 20200606-1753-trace.nettrace.chromium.json 控制在 1.5G 了,

終於可以正常加載起來了。

Chrome Performance

首先, 我們看到監控裏面有一堆的線程

隨便選一個線程看看它做撒,選擇 Call Tree 之後 點點點點點。

從調用棧能看到 整個線程當前狀態是“PerformWaitCallback”

整個操作應該的開頭應該是

Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.KestrelConnection.System.Threading.IThreadPoolWorkItem.Execute()

PS: Kestrel (https://github.com/aspnet/KestrelHttpServer) is a lightweight cross-platform web server that supports .NET Core and runs on multiple platforms such as Linux, macOS, and Windows. Kestrel is fully written in .Net core. It is based on libuv which is a multi-platform asynchronous eventing library.

PS 人話: .NET Core 內置的 HTTP Server,和 Spring Boot 中的 tomcat 組件類似

很正常,說明請求正常到了我們的服務裏面了。

再看一下剩下的調用鏈信息。

簡要的調用信息日誌在這裏:


System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start(!!0&)
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Infrastructure.KestrelConnection+<ExecuteAsync>d__32.MoveNext()
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.HttpConnectionMiddleware`1[System.__Canon].OnConnectionAsync(class Microsoft.AspNetCore.Connections.ConnectionContext)   Microsoft.AspNetCore.Server.Kestrel.Core.Internal.HttpConnection.ProcessRequestsAsync(class Microsoft.AspNetCore.Hosting.Server.IHttpApplication`1<!!0>)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(!!0&)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start(!!0&)
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.HttpConnection+<ProcessRequestsAsync>d__12`1[System.__Canon].MoveNext()
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync(class Microsoft.AspNetCore.Hosting.Server.IHttpApplication`1<!!0>)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(!!0&)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start(!!0&)
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequestsAsync>d__216`1[System.__Canon].MoveNext()
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests(class Microsoft.AspNetCore.Hosting.Server.IHttpApplication`1<!!0>)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(!!0&)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start(!!0&)
Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol+<ProcessRequests>d__217`1[System.__Canon].MoveNext()
Microsoft.AspNetCore.Hosting.HostingApplication.ProcessRequestAsync(class Context)
Microsoft.AspNetCore.HostFiltering.HostFilteringMiddleware.Invoke(class Microsoft.AspNetCore.Http.HttpContext)
UserCenter.ErrorHandlingMiddleware.Invoke(class Microsoft.AspNetCore.Http.HttpContext)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(!!0&)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start(!!0&)

......
......
......

e.StaticFiles.StaticFileMiddleware.Invoke(class Microsoft.AspNetCore.Http.HttpContext)
Microsoft.AspNetCore.Builder.UseMiddlewareExtensions+<>c__DisplayClass4_1.<UseMiddleware>b__2(class Microsoft.AspNetCore.Http.HttpContext)
dynamicClass.lambda_method(pMT: 00007FB6D3BBE570,class System.Object,pMT: 00007FB6D4739560,pMT: 00007FB6D0BF4F98)
Microsoft.AspNetCore.Builder.UseMiddlewareExtensions.GetService(class System.IServiceProvider,class System.Type,class System.Type)
Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceProviderEngineScope.GetService(class System.Type)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(!!0&)

Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor`2[Microsoft.Extensions.DependencyInjection.ServiceLookup.RuntimeResolverContext,System.__Canon].VisitCallSite(class Microsoft.Extensions.DependencyInjection.ServiceLookup.ServiceCallSite,!0)
System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start(!!0&)
System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start(!!0&)

看到這裏,其實又有了一些很給力的信息被暴露出來了。

PerformWaitCallback

  • 直接字面理解,線程正在執行等待回調

調用鏈信息

耐心點,把所有的電調用鏈都展開。

我們能看到程序已經依次經過了下面幾個流程:

->ProcessRequestsAsync(系統)

->ErrorHandlingMiddleware(已經加載了自定義的錯誤中間件)

-> HostFilteringMiddleware(加載了 Filter 中間件)

-> Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteVisitor(調用鏈中的最後一個操作)

對應最上面的日誌來說,

請求進來,經過了中間件和 Filter 都是沒問題的,

最後在 DependencyInjection(依賴注入) 中沒有了蹤跡。

到這裏,

再次驗證我們昨天的思路:

這是一個 “資源阻塞問題”產生的問題

雖然做 ptrace 是想能直接抓到“兇手”的,

最後發現並沒有能跟蹤到具體的實現,

那可咋辦呢?

控制變量實踐

已知:

  • 併發 300 訪問 /v1/user/test/account-balance 接口程序會假死
  • 移除 Filter 中間件不能解決問題
  • 併發 300 訪問 /v1/health 健康檢查接口程序正常
  • ptrace 信息告訴我們有“東西”在阻塞 DI 容器創建某些實例

開始控制變量 + 人肉二分查找。

挪接口代碼

/v1/user/test/account-balance 的邏輯是由 AccountService 實現的,

AccountService 大概依賴四五個其他的 Service 和 DBContext,

最主要的邏輯是加載用戶幾個賬號,然後計算一下 balance。

大概代碼如下:

/// <summary>
/// 獲取用戶的AccountBalance匯總信息
/// </summary>
public async Task<AccountBalanceStat> LoadAccountBalanceStatAsync(string owner)
{
    // 數據庫查詢
    var accounts = await _dbContext.BabelAccounts.Where(ac => ac.Owner == owner).ToListAsync();
    // 內存計算
    return ConvertToAccountBalanceStat(accounts);
}

什麼都不改,直接把代碼 CP 到 Health 接口測一下。

神奇,300 併發抗住了。

結論:

  • 上面這一段代碼並不會導致服務僵死
  • 數據庫驅動沒有問題,DbContext 沒有問題,數據庫資源使用沒有問題
  • 當前並不會觸發 DI 容器異常, 問題出在 /v1/user/test/account-balance 初始化

account-balance 有什麼神奇的東西嗎?


/// <summary>
/// 查詢用戶的Brick賬號餘額
/// </summary>
[HttpGet("v1/user/{owner}/account-balance")]
[SwaggerResponse(200, "獲取成功", typeof(AccountBrickStat))]
public async Task<IActionResult> GetAccountBricks(
    [FromRoute, SwaggerParameter("所有者", Required = true)] string owner)
{
    owner = await _userService.FindOwnerAsync(owner);
    return Ok(new { data = await _accountService.LoadAccountAsync(owner), code = 0 });
}

我們剛剛驗證了 LoadAccountAsync 的代碼是沒有問題的,

要不 UserService DI 有問題,要不 AccountService DI 有問題。

把 UserService 加入到 HealthController 中。


public HealthController(UserService userService, UserPoolDataContext dbContext)
{
    _dbContext = dbContext;
    _userService= userService;
}

Bool。

300 併發沒有撐住,程序僵死啦。

完美,

問題應該在 UserService DI 初始化了。

接下來就是一個個驗證 UserService DI 需要的資源,

EmailSDK 沒有問題,

HTTPHeaderTools 沒有問題,

UserActivityLogService 沒有問題。

RedisClient…
RedisClient…
RedisClient…

OK
OK
Ok

復現炸雞了。

原來是 Redis 的鍋?

是,

也不是。

先看下我們 RedisClient 是怎麼使用的。

// startup.cs 注入了單例的ConnectionMultiplexer
// 程序啟動的時候會調用InitRedis
private void InitRedis(IServiceCollection services)
{
    services.AddSingleton<ConnectionMultiplexer, ConnectionMultiplexer>(factory =>
    {
        ConfigurationOptions options = ConfigurationOptions.Parse(Configuration["RedisConnectionString"]);
        options.SyncTimeout = 10 * 10000;
        return ConnectionMultiplexer.Connect(options);
    });
}

//RedisClient.cs 通過構造函數傳入

public class RedisClient
{
    private readonly ConnectionMultiplexer _redisMultiplexer;

    private readonly ILogger<RedisClient> _logger;

    public RedisClient(ConnectionMultiplexer redisMultiplexer, ILogger<RedisService> logger)
    {
        _redisMultiplexer = redisMultiplexer;
        _logger = logger;
    }
}

DI 初始化 RedisClient 實例的時候,

需要執行 ConnectionMultiplexer.Connect 方法,

ConnectionMultiplexer.Connect 是同步阻塞的。

ConnectionMultiplexer.Connect 是同步阻塞的。

ConnectionMultiplexer.Connect 是同步阻塞的。

一切都能解釋了。

怎麼改?

// InitRedis 直接把鏈接創建好,然後直接注入到IServiceCollection中
private void InitRedis(IServiceCollection services)
{
    ConfigurationOptions options = ConfigurationOptions.Parse(Configuration["RedisConnectionString"]);
    options.SyncTimeout = 10 * 10000;
    var redisConnectionMultiplexer = ConnectionMultiplexer.Connect(options);
    services.AddSingleton(redisConnectionMultiplexer);
    Log.Information("InitRedis success.");
}

發布驗證,

開門放併發 300 + 3000 請求。

完美抗住,絲一般順滑。

還有更優的寫法嗎?

  • 看了下微軟 Cache 中間件源碼,更好的做法應該是通過信號量+異步鎖來創建 Redis 鏈接,下來再研究一下
  • 數據庫中可能也存在類似的問題,不過當前會在 Startup 中戳一下數據庫連接,應該問題不大。

復盤

程序啟動的時候依賴注入容器同步初始化 Redis 可能很慢(幾秒甚至更長)的時候,

其他的資源都在同步等待它初始化好,

最終導致請求堆積,引起程序雪崩效應。

Redis 初始化過慢並不每次都發生, 所以之前服務也只是偶發。

DI 初始化 Redis 連接的時候,redis 打來連接還是個同步的方法,

這種情況下還可能發生異步請求中等待同步資源產生阻塞問題。

同時還需要排查使用其他外部資源的時候是否會觸發同類問題。

幾個通用的小技巧

  • ptrace 對此類問題分析很有意義,不同語言框架都有類似的實現

  • 同步、異步概念的原理和實現都要了解,這個有利於理解一些奇奇怪怪的問題

  • 火焰圖、Chrome dev Performance 、speedscope 都是好東西

  • Debug 日誌能給更多的信息,在隔離生產的情況下大膽使用

  • 這輩子都不可能看源碼的,寫寫 CURD 多美麗?源碼真香,源碼真牛逼。

  • 控制變量驗證,大膽假設,小心求證,人肉二分查,先懷疑自己再懷疑框架

  • 搞事的時候不要自己一個人,有 Bug 一定要拉上小夥伴一起吃

相關資料

  • IBM Developer ptrace 嵌入式系統中進程間通信的監視方法

  • 分析進程調用 pstack 和 starce

  • pstack 显示每個進程的棧跟蹤

  • 微軟:dotnet-trace performance analysis utility

  • 知乎:全新 Chrome Devtool Performance 使用指南

  • speedscope A fast, interactive web-based viewer for performance profiles.

  • jdk 工具之 jstack(Java Stack Trace)

  • 阮一峰:如何讀懂火焰圖?

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價

記一次Docker中Redis連接暴增的問題排查

3{icon} {views}

周六生產服務器出現redis服務器不可用狀態,錯誤信息為:

狀態不可用,等待後台檢查程序恢復方可使用。Unexpected end of stream; expected type ‘Status’

如下圖所示,下圖6300就是我們redis服務器運行的端口。

 

頭一次碰到此類問題,心想難道是redis掛掉了,隨即通過telnet ip+端口。發現運行正常,然後就想着進入redis看下目前連接情況。一看發現竟然高達1903條這麼多。

然後想着應該是代碼創建redis連接過多導致的,查看代碼。

發現redis創建只有這一個地方有,這裏也是服務註冊時才執行。也就是應用程序啟動時才被執行一次。然後整個項目查找,沒有其他地方再有調用redis初始化。

心有不甘,難道是每次在redis讀寫數據時都會創建連接嗎?會和讀寫頻繁有關係嗎?總感覺不會啊,隨即創建測試代碼進行測試一番。

在本地搭建了一個redis環境,測試之前先看看接數多少,目前看只有1個,也就是目前的cmd連接客戶端,這個屬於正常的了。

開始測試,運行程序。代碼是創建一個連接對象,並一共測試1000次寫,和1000次讀。

 

不管我怎麼測試連接都是6個,那麼也就是說我們程序最多創建了5個連接,當然主要有線程池在裏面。

 

所以基本的存儲讀取這塊代碼肯定是沒問題。

但代碼這塊也沒算完全放棄排查,因為生產服務器通過docker運行着大約6個應用程序。都是連接的同一個redis,會不會是其他應用程序導致的?

然後就想直接通過redis 連接列表裡的中隨便一個端口來查詢對應的進程信息就可以知道是哪些應用程序了。

Linux 中通過查詢網絡端口號显示進程信息。

netstat -atunlp | grep 60852 

首先看這端口對應的IP,比如這裏第一個是172.17.0.1。熟悉docker的同學應該知道這個ip是docker網關IP。我們容器中的程序都是通過這個網關IP來和我們宿主主機來通訊的。我們通過ifconfig就能發現docker這個網關IP,第二個172.17.0.3:6379這個一看就是redis的容器IP,

這樣一看確實無法找到具體對應哪個容器中的程序和我們建立連接的。

有一個最笨的辦法就是挨個進入容器裏面。即docker exec –it test /bin/bash 然後查看當前容器的網絡連接情況。這樣非常麻煩,並且需要安裝很多組件才能執行一系列命令。

另外一個辦法lsof命令,如果沒有則需要安裝。我們可以通過進程去找所有網絡連接情況。

比如我們剛發現我們的進程主要是docker,他的pid是582251。

lsof -i |grep 582251或者 lsof -i -p 582251

結果如下圖,右邊其實出現了具體IP,這個IP就是docker容器具體的IP地址。

 

現在知道所有IP和端口了,我們將命令執行結果下載下來。

首先找到自己每個容器對應的IP。

docker inspect name |grep IPAddress    //name 容器名稱或者id

 

找到每個ip后然後根據剛下載的所有網絡連接信息進行統計,看哪個IP連接最多,最多的一個肯定有問題。

然後我就找到這個IP對應的容器部署的程序,然後看redis配置。發現線程池設為200。

另外我通過github,發現CSRedisCore還有個預熱機制,也就是preheat,他默認值就是5個預熱連接。

我們線程池設置的是200加上本身有個預熱機制5個連接,我不知道是不是會創建200*5=1000個。這個有時間再好好研究下源代碼,目前只是猜測。

我現在已經將redis修改為poolsize=5, preheat=false。線程池5個,並且關閉預熱機制。

 

修改我們連接配置,並重啟應用服務器和redis服務器(為了徹底清除已建立的連接)后發現連接數有減少,但沒有很多。後來查詢發現,是redis的idle空閑時長太長,導致連接池維持太多連接,沒有被釋放。

我們設置下超時為30s

執行CONFIG SET timeout 30 (單位是秒,此種方式只是臨時修改,針對當前運行有效。長效記得修改redis配置文件)

然後再看下連接數多少,這樣一下子就減少了很多。

總結:

1、 redis連接暴增,首先從自身應用程序出發去尋找問題,比如我這邊發現的連接池設置過大,加上默認的預熱機制等。還有盡可能的看代碼層面在創建連接是否會被多次觸發,如果有就必須要改正。現在都是通過注入的方式創建實例,要看該地方是存在被多次調用。

2、修改redis服務器配置,比如連接空閑超時時間。包括也可也看下最大連接數多少,默認值。

 

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

【其他文章推薦】

※回頭車貨運收費標準

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

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

※推薦評價好的iphone維修中心

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

台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

蘇門答臘高速公路通車前夕驚見虎蹤 生態廊道功效恐不足 專家建議另增柵欄

3{icon} {views}

環境資訊中心綜合外電;范震華 翻譯;賴慧玲 審校;稿源:Mongabay

本站聲明:網站內容來源環境資訊中心https://e-info.org.tw/,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

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

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

※回頭車貨運收費標準

※推薦評價好的iphone維修中心

※超省錢租車方案

台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

※推薦台中搬家公司優質服務,可到府估價