解Bug之路-記一次存儲故障的排查過程

高可用真是一絲細節都不得馬虎。平時跑的好好的系統，在相應硬件出現故障時就會引發出潛在的Bug。偏偏這些故障在應用層的表現稀奇古怪，很難讓人聯想到是硬件出了問題，特別是偶發性出現的問題更難排查。今天，筆者就給大家帶來一個存儲偶發性故障的排查過程。

Bug現場

我們的積分應用由於量非常大，所以需要進行分庫分表，所以接入了我們的中間件。一直穩定運行，但應用最近確經常偶發連接建立不上的報錯。報錯如下:

GetConnectionTimeOutException

而筆者中間件這邊收到的確是:

NIOReactor - register err java.nio.channels.CloasedChannelException 

這樣的告警。整個Bug現場如下圖所示:

偶發性錯誤

之前出過類似register err這樣的零星報警，最後原因是安全掃描，並沒有對業務造成任何影響。而這一次，類似的報錯造成了業務的大量連接超時。由於封網，線上中間件和應用已經穩定在線上跑了一個多月，代碼層面沒有任何改動！突然出現的這個錯誤感覺是環境出現了某些問題。而且由於線上的應用和中間件都是集群，出問題時候都不是孤立的機器報錯，沒道理所有機器都正好有問題。如下圖所示:

開始排查是否網絡問題

遇到這種連接超時，筆者最自然的想法當然是網絡出了問題。於是找網工進行排查，
在監控裏面發現網絡一直很穩定。而且如果是網絡出現問題，同一網段的應用應該也都會報錯
才對。事實上只有對應的應用和中間件才報錯，其它的應用依舊穩穩噹噹。

又發生了兩次

就在筆者覺得這個偶發性問題可能不會再出現的時候，又開始抖了。而且是一個下午連抖了兩次。臉被打的啪啪的，算了算了，先重啟吧。重啟中間件后，以為能消停一會，沒想到半個小時之內又報了。看來今天不幹掉這個Bug是下不了班了!

開始排查日誌

事實上，筆者一開始就發現中間件有調用後端數據庫慢SQL的現象，由於比較偶發，所以將這個現象發給DBA之後就沒有繼續跟進,DBA也反饋SQL執行沒有任何異常。筆者開始認真分析日誌之後，發現一旦有 中間件的register err 必定會出現中間件調用後端數據庫的sql read timeout的報錯。
但這兩個報錯完全不是在一個線程裏面的，一個是處理前端的Reactor線程，一個是處理後端SQL的Worker線程，如下圖所示:

這兩個線程是互相獨立的，代碼中並沒有發現任何機制能讓這兩個線程互相影響。難道真是這些機器本身網絡出了問題？前端APP失敗，後端調用DB超時，怎麼看都像網絡的問題！

進一步進行排查

既然有DB(數據庫)超時，筆者就先看看調用哪個DB超時吧，畢竟後面有一堆DB。筆者突然發現，和之前的慢SQL一樣，都是調用第二個數據庫超時，而DBA那邊卻說SQL執行沒有任何異常，

筆者感覺明顯SQL執行有問題，只不過DBA是採樣而且將採樣耗時平均的，偶爾的幾筆耗時並不會在整體SQL的耗時裏面有所體現。

只能靠日誌分析了

既然找不到什麼頭緒，那麼只能從日誌入手，好好分析推理了。REACTOR線程和Worker線程同時報錯，但兩者並無特殊的關聯，說明可能是同一個原因引起的兩種不同現象。筆者在線上報錯日誌裏面進行細細搜索，發現在大量的

NIOReactor-1-RW register err java.nio.channels.CloasedChannelException

日誌中會摻雜着這個報錯:

NIOReactor-1-RW Socket Read timed out
	at XXXXXX . doCommit
	at XXXXXX Socket read timedout

這一看就發現了端倪，Reactor作為一個IO線程，怎麼會有數據庫調用呢?於是翻了翻源碼，原來，我們的中間件在處理commit/rollback這樣的操作時候還是在Reactor線程進行的！很明顯Reactor線程卡主是由於commit慢了!筆者立馬反應過來,而這個commit慢也正是導致了regsiter err以及客戶端無法創建連接的元兇。如下面所示:

由於app1的commit特別慢而卡住了reactor1線程，從而落在reactor1線程上的握手操作都會超時！如下圖所示:

為什麼之前的模擬宕機測試發現不了這一點

因為模擬宕機的時候，在事務開始的第一條SQL就會報錯，而執行SQL都是在Worker線程裏面，
所以並不會觸發reactor線程中commit超時這種現象，所以測試的時候就遺漏了這一點。

為什麼commit會變慢?

系統一直跑的好好的，為什麼突然commit就變慢了呢，而且筆者發現，這個commit變慢所關聯的DB正好也是出現慢SQL的那個DB。於是筆者立馬就去找了DBA,由於我們應用層和數據庫層都沒有commit時間的監控(因為一般都很快，很少出現慢的現象)。DBA在數據庫打的日誌裏面進行了統計，發現確實變慢了，而且變慢的時間和我們應用報錯的時間相符合！
順藤摸瓜，我們又聯繫了SA，發現其中和存儲相關的HBA卡有報錯！如下圖所示:

報錯時間都是一致的！

緊急修復方案

由於是HBA卡報錯了，屬於硬件故障，而硬件故障並不是很快就能進行修復的。所以DBA做了一次緊急的主從切換，進而避免這一問題。

一身冷汗

之前就有慢sql慢慢變多，而後突然數據庫存儲hba卡宕機導致業務不可用的情況。
而這一次到最後主從切換前為止，報錯越來越頻繁，感覺再過一段時間,HBA卡過段時間就完全不可用，重蹈之前的覆轍了！

中間件修復

我們在中間件層面將commit和rollback操作挪到Worker裏面。這樣，commit如果卡住就不再會引起創建連接失敗這種應用報錯了。

總結

由於軟件層面其實是比較信任硬件的，所以在硬件出問題時，就會產生很多詭異的現象，而且和硬件最終的原因在表面上完全產生不了關聯。只有通過抽絲剝繭，慢慢的去探尋現象的本質才會解決最終的問題。要做到高可用真的是要小心評估各種細節，才能讓系統更加健壯！

公眾號

關注筆者公眾號，獲取更多乾貨文章:

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

【其他文章推薦】

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

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

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

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

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

※超省錢租車方案

1.UniRx 簡介

UniRx 是一個 Unity3D 的編程框架。它專註於解決時間上異步的邏輯，使得異步邏輯的實現更加簡潔和優雅。

簡潔優雅如何體現？

比如，實現一個“只處理第一次鼠標點擊事件”這個功能，使用 UniRx 實現如下:

Observable.EveryUpdate()
			.Where(_ => Input.GetMouseButtonUp(0))
			.First()
			.Subscribe(_ => { // do something   });

代碼做的事情很簡單:

1. 開啟一個 Update 的事件監聽。
2. 每次 Update 事件被調用時，進行鼠標是否抬起的判斷。
3. 如果判斷通過，則進行計數，並且只獲取第一次點擊事件。
4. 訂閱/處理事件。

如果在 Unity 中，使用傳統的方式實現如上功能，首先要創建一個成員變量來記錄點擊次數/是否點擊過，然後在腳本中創建一個 Update 方法來監聽鼠標抬起的事件。

如果在 Update 方法中，除了實現鼠標事件監聽這個功能之外，還要實現其他的功能。那麼 Update 里就會充斥着大量的狀態判斷等邏輯。代碼非常不容易閱讀。

而 UniRx 提供了一種編程思維，使得平時一些比較難以實現的異步邏輯（比如以上這種），使用 UniRx 輕鬆搞定，並且不失代碼的可讀性。

當然 UniRx 的強大不僅僅如此。

它還可以：

• 優雅實現 MVP（MVC）架構模式。
• 對 UGUI/Unity API 提供了增強，很多需要寫大量代碼的 UI 邏輯，使用 UniRx 優雅實現。
• 輕鬆完成非常複雜的異步任務處理。
• ……

最最重要的是，它可以提高我們的編碼效率，同時還給我們的大腦提供一個強有力的編程模型。而 UniRx 本身的源碼非常值得研究學習，就連大名鼎鼎的 uFrame 框架，在 1.6 版本之後，使用 UniRx 進行了大幅重構，其事件/數據綁定層使用 UniRx 強力驅動。

筆者的 QFramework 也同樣引入了 UniRx，有一大批的框架用戶都是因為支持了 UniRx 慕名而來。

為什麼要用 UniRx ?

UniRx 就是 Unity 版本的 Reactive Extensions，Reactive Extensions 中文意思是：響應式擴展，響應式指的是觀察者和定時器，擴展指的是 LINQ 的操作符。Reactive Extensions 以擅長處理時間上異步的邏輯、以及極簡的 API 風格而聞名。

我們都知道，遊戲很多的系統都是在時間上異步的，所以 Unity 開發者所需要實現的異步邏輯是非常多的。這也是為什麼 Unity 官方在引擎層實現了 Coroutine（協程）這樣的概念。

在遊戲中，像動畫的播放、聲音的播放、網絡請求、資源加載/卸載、Tween 動畫、場景過渡等都是在時間上異步的邏輯。甚至是遊戲循環（Every Update、OnCollisionEnter 等）、傳感器數據（Kinect、Leap Motion、VR Input 等）都是時間上異步的邏輯（事件）。

當我們在項目中實現以上的邏輯的時候，往往使用的方式是用大量的回調實現，最終隨着項目的擴張會導致傳說中的”回調地獄”。

相對較好的方法則是使用消息/事件進行實現，結果導致“消息滿天飛”，導致代碼非常難以閱讀。

以上的任務使用 Coroutine 也是非常不錯的，但是 Coroutine 在 Unity 使用的時候，需要定義一個方法。寫起來是非常面向過程的。當邏輯稍微複雜一點，就很容易造成 Coroutine 嵌套 Coroutine，代碼是非常不容易閱讀的（強耦合）。

而 UniRx 的出現剛好解決了這個問題，它介於回調和事件之間。

它有事件的概念，只不過它的事件是像流水一樣流過來，而我們要做的則是簡單地對這些事件進行組織、變換、過濾、合併就可以得到我們想要的結果了。

它也用掉了回調，只不過它的回調是在事件經過組織之後，只需要調用一次就可以進行事件處理了。

它的原理和 Coroutine （迭代器模式）、LINQ 非常相似，但是比 Coroutine 強大得多。

UniRx 將時間上異步的事件轉化為響應式的事件序列，通過 LINQ操作可以很簡單地組合起來。

為什麼要用 UniRx？ 答案就是遊戲本身有大量的在時間上異步的邏輯，而 UniRx 恰好擅長處理這類邏輯，使用 UniRx 可以節省我們的時間，同時讓代碼更簡潔易讀。

Rx 只是一套標準，其他的語言也有實現，如果在 Unity 中熟悉了這套標準，那麼在未來，大家在做別的語言的項目的時候，很容易獲得 Rx 的能力。

專欄內容：

1. 實踐並講解開發中最常用的 UniRx API。
2. 對 UniRx 進行一個全方面的簡介。
3. 在每個階段結束后就會結合所學的知識進行項目實踐。
4. UniRx 操作符大全。
5. UniRx 源碼閱讀。
6. UniRx 背後的設計原理及設計模式學習。
7. LINQ、Coroutine 底層原理剖析。
8. BindingsRx、uFrame 源碼閱讀。

OK，讓我們從下一篇開始，感受一下 UniRx 的魅力吧。

知識地圖

2.定時功能實現

在 Unity 開發中，延時是我們經常要實現的功能，這個功能對於有點經驗的開發者來說不難。

最常見的實現方式如下：

using UnityEngine;

public class CommonDelayExample : MonoBehaviour
{
	private float mStartTime;

	void Start()
	{
		mStartTime = Time.time;
	}

	void Update()
	{
		if (Time.time - mStartTime > 5)
		{
			DoSomething();
			// 避免再次執行
			mStartTime = float.MaxValue;
		}
	}

	void DoSomething()
	{
		Debug.Log("DoSomething");
	}
}

這是很多初學者剛入門時候的實現方式，而初學者們隨着深入學習後來接觸到了 Coroutine（協程），使用 Coroutine 實現定時功能會更容易，而且也是更好的選擇，實現如下：

using System;
using System.Collections;
using UnityEngine;

public class CoroutineDelayExample : MonoBehaviour
{
	void Start()
	{
		StartCoroutine(Timer(5, DoSomething));
	}

	IEnumerator Timer(float seconds, Action callback)
	{
		yield return new WaitForSeconds(seconds);
		callback();
	}

	void DoSomething()
	{
		Debug.Log("DoSomething");
	}
}

協程已經把代碼精簡了很多，不過接下來有更厲害的，使用 UniRx。

代碼如下：

Observable.Timer(TimeSpan.FromSeconds(5)).Subscribe(_ => { /* do something */ });

當然以上代碼是沒有和 MonoBehaviour 進行生命周期綁定的，也就是說當 MonoBehaviour 銷毀了之後，這個定時邏輯可能還在執行，這樣就會有造成空指針異常的風險。

要解決也很簡單，代碼如下:

Observable.Timer(TimeSpan.FromSeconds(5))
		.Subscribe(_ => { /* do something */ })
		.AddTo(this);

只要加上一個 AddTo(this) 就可以了。
這樣，當 this(MonoBehaviour) Destroy 的時候，這個延時邏輯也會銷毀掉，從而避免造成空指針異常。

三行代碼，寫下來大約 20 秒的時間，就搞定了一個實現起來比較麻煩的邏輯。

今天的內容就這些。

知識地圖

更多內容

• QFramework 地址：https://github.com/liangxiegame/QFramework
• QQ 交流群：623597263
• 涼鞋的主頁：https://liangxiegame.com/zhuanlan
• 關注公眾號：liangxiegame 獲取第一時間更新通知及更多的免費內容。

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

【其他文章推薦】

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

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

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

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

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

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

引子

 有一本講諾貝爾獎獲得者，物理學家費曼的書，叫做《發現的樂趣》，書中寫到一個費曼小時候的故事：

 “我們家有《大不列顛百科全書》，我還是小孩子的時候，父親就常常讓我坐在他腿上，給我讀些《大不列顛百科全書》。比如說，我們讀關於恐龍的部分，書上可能講雷龍或其他什麼龍，書上會說：“這傢伙有 25 英尺高，腦袋寬 6 英尺。” 

這時父親就停下來，說：“我們來看看這句話什麼意思。這句話的意思是：假如它站在我們家的前院里，它是那麼高，高到足以把頭從窗戶伸進來。不過呢，它也可能遇到點麻煩，因為它的腦袋比窗戶稍微寬了些，要是它伸進頭來，會擠破窗戶。 

費曼說：凡是我們讀到的東西，我們都盡量把它轉化成某種現實，從這裏我學到一個本領——凡我所讀的內容，我總設法通過某種轉換，弄明白它究竟什麼意思，它到底在說什麼。

費曼技巧

費曼技巧，或者說費曼學習法是一種以教促學的方法，一共有四步（已經知道的可以無視，直接跳過）: 

(1) 選擇新概念/新知識， 自己先去學習它。 

(2) 假裝當一個老師，去教授別人 

想象你面對一群小白，怎麼把這個概念講給他們聽，讓他們理解呢？ 

把你講解的思路也寫到紙上，如果實在不想寫，可以說出來。 

非常重要！！！不要讓你的思路停留在大腦中，因為大腦中對於知識點之間的關聯會有些想當然的、錯誤的假設，說出來或者寫出來能找到這些“盲點”！！

(3) 如果你在教授的過程中遇到了麻煩，卡了殼，返回去學習。 

重新去看書，搜相關資料，問別人，倒逼自己把這個概念搞清楚， 然後回到第二步，繼續給小白講授。

(4) 簡化你的語言。 

目標是用你自己的語言，非專業的詞彙去解釋這個概念。盡量做到簡單直白，或者找到比喻來表達。 

非常簡單的過程，對吧？ 

實戰演練

我們來用個例子來演練一下，有請碼農翻身頭號主人公張大胖出場。 

張大胖正在學習Java，這一天他遇到了一個新的概念：“動態代理”  （注意是學習這個概念，不是具體實現）， 非常抽象，在日常編程中幾乎不會直接使用，理解起來有難度。

第一步，自學

 張大胖看了動態代理的介紹，書上列舉出一堆煩人的代碼來展示這個東西是怎麼使用的，比如有個接口(IHelloWorld)及其實現類(HelloWorld)， 然後有個InvocationHandler的實現，最後用Proxy.newProxyInstance(….)創建一個新的類出來，這些都是什麼鬼？啰里啰唆的。

第二步，張大胖嘗試教一下小白(當然這裏的小白至少得懂點兒Java)

張大胖：動態代理嘛，很簡單，就是給定一個接口和實現類，再加上一個InvocationHandler ， 動態代理這個技術可以在運行時創建一個新的代理類出來。 

小白：張老師， 新的代理類有什麼用？ 

張大胖：舉個例子，有個叫IHelloWorld接口及其實現類HelloWorld，它有一個叫sayHello()的方法。可以在sayHello()之前和之後，額外加一些日誌的輸出。 

（在講解一個概念的時候，舉例和類比很重要，人類習慣於通過例子來學習，從具體走向抽象） 

小白：那我直接寫一個新的類，比如HelloWorldEx，把日誌輸出添加到其中不就行了，為什麼還要用Proxy.newProxyInstance（……）這麼麻煩的方法？

public class HelloWorldEx implements IHelloWorld{
    IHelloWorld hw;
    public HelloWorldEx(IHelloWorld hw){
        this.hw = hw;
    }    
    public void sayHello(){        
        Logger.startLog();
        hw.sayHello();
        Logger.endLog();
    }
}

張大胖無法回答這個問題，卡殼了！ 

第三步，回過頭去看書，學習。

書中也沒有解釋，唉！ 

仔細想一想，手動寫一個類HelloWorldEx和用Proxy.newProxyInstance來創建，區別到底是什麼？ 

實現的功能是相同的，但是HelloWorldEx需要事先寫好，編譯后不能改了，相當於寫死了！如果我想對Order類，Employee類，Department類，也想加點兒日誌，還得寫個OrderEx，EmployeeEx，DepartmentEx的類，太麻煩了！ 

而Proxy.newProxyInstance這種方法，可以在程序運行的時候為任意類動態地創建增強的類。 

事先寫死的叫做靜態代理，Proxy.newProxyInstance這種方式叫做動態代理，更加靈活。 

張大胖覺得這麼解釋就通了。 

小白：為什麼要創建新的代理類，那個Proxy.newProxyInstance不能直接修改老的HelloWorld類嗎？ 

張大胖再度卡殼，上網搜索，找到了答案，和Python,Ruby等方法不同，Java本質是一個靜態類型的語言，class一旦被裝入JVM，是不能修改，添加，刪除方法的，既然老的class不能修改，只能通過代理的方式來創建新的類了。 

小白：懂了，這個技術主要用在什麼地方啊? 難道只是加個日誌？ 

張大胖第三次卡殼，只好再次搜索。 

原來動態代理使用得最多的是AOP，AOP中經常會以聲明的方式提出這樣的要求： 

某個包下所有add開頭的方法，在執行之前都要調用Logger.startLog()方法，在執行之後都要調用Logger.endLog()方法。 

或者對於所有以Service結尾的類，所有的方法執行之前都要調用tx.begin()，執行之後都要調用tx.commit(), 如果拋出異常的話調用tx.rollback()。

到此為止，張大胖可以這樣來給小白講述了： 

你不是用過Spring AOP嗎？AOP中經常有這樣的需求……  ，Spring想添加這些日誌和事務的功能，但是卻沒有辦法去修改用戶的類，它是框架啊，一是不知道用戶類的源碼，二是Java不允許再修改裝載入JVM的class。 

沒辦法，Spring只好在運行時找到用戶的類，然後操作字節碼動態創建一個新類，新類會對原有的類進行增強，添加日誌，事務這些功能，注意啊，這些都是在內存中動態創建的。 

這個技術就是Java的動態代理，不過它有個前提要求，就是用戶的類需要實現接口才行。我用一個簡單的例子給你說下，你就明白細節了……

第四步，簡化，比喻

上面的講解從文字上來說還是非常啰嗦的，用了很大篇幅來講解“為什麼”，因為理解了why ，剩下的就是細節了。  

如果你徹底理解了以後，動態代理的技術細節會在大腦中會建立這麼一幅圖景：

$HelloWorld100就是那個代理類，它和HelloWorld都實現了IHelloWorld這個接口。 

如果一定要用個比喻來說，它們倆就是“兄弟關係”，CgLib提供了另外一種對現有類增強的辦法，動態生成的類繼承了現有的類，兩者是“父子關係”。

小結

 怎麼樣？用這種（假裝）教授別人，層層遞進、自我逼問的方法是不是很有效果？收益很大？  

用這種辦法，實際上就是逼着你把大腦中的盲點和一些想當然的假設給暴露出來，效果要比單純地閱讀和記憶好得多，趕緊在學習中試一下吧！

更多精彩文章，盡在碼農翻身

我是一個線程

TCP/IP之大明郵差

一個故事講完Https

CPU 阿甘

Javascript: 一個屌絲的逆襲

微服務把我坑了

如何降低程序員的工資？

程序員，你得選准跑路的時間！

兩年，我學會了所有的編程語言！

一直CRUD，一直996，我煩透了，我要轉型

字節碼萬歲！

上帝託夢給我說：一切皆文件

Node.js :我只需要一個店小二

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

【其他文章推薦】

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

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

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

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

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

Netty 出發點作為一款高性能的 RPC 框架必然涉及到頻繁的內存分配銷毀操作，如果是在堆上分配內存空間將會觸發頻繁的GC，JDK 在1.4之後提供的 NIO 也已經提供了直接直接分配堆外內存空間的能力，但是也僅僅是提供了基本的能力，創建、回收相關的功能和效率都很簡陋。基於此，在堆外內存使用方面，Netty 自己實現了一套創建、回收堆外內存池的相關功能。基於此我們一起來看一下 Netty 是如何實現內存分配的。

1. Netty 中的數據容器分類

談到數據保存肯定要說到內存分配，按照存儲空間來劃分，可以分為 堆內存 和 堆外內存；按照內存區域連貫性來劃分可以分為池化內存和非池化內存。這些劃分在 Netty 中的實現接口分別是：

按照底層存儲空間劃分：

• 堆緩衝區：HeapBuffer；
• 直接緩衝區：DirectBuffer。

按照是否池化劃分：

• 池化：PooledBuffer；
• 非池化：UnPooledBuffer。

默認使用 PoolDireBuf 類型的內存, 這些內存主要由 PoolArea 管理。另外 Netty 並不是直接對外暴露這些 API，提供了 Unsafe 類作為出口暴露數據分配的相關操作。

小知識：

什麼是池化？

一般申請內存是檢查當前內存哪裡有適合當前數據塊大小的空閑內存塊，如果有就將數據保存在當前內存塊中。

那麼池化想做的事情是：既然每次來數據都要去找內存地址來存，我就先申請一塊內存地址，這一塊就是我的專用空間，內存分配、回收我全權管理。

池化解決的問題：

內存碎片：

內碎片

內碎片就是申請的地址空間大於真正數據使用的內存空間。比如固定申請1M的空間作為某個線程的使用內存，但是該線程每次最多只佔用0.5M，那麼每次都有0.5M的碎片。如果該空間不被有效回收時間一長必然存在內存空洞。

外碎片

外碎片是指多個內存空間合併的時候發現不夠分配給待使用的空間大小。比如有一個 20byte，13byte 的連續內存空間可以被回收，現在有一個 48byte 的數據塊需要存儲，而這兩個加起來也只有 33byte 的空間，必然不會被使用到。

如何實現內存池？

1. 鏈表維護空閑內存地址

   最簡單的就是弄一個鏈表來維護當前空閑的內存空間地址。如果有使用就從鏈表刪除，有釋放就加入鏈表對應位置。這種方式實現簡單，但是搜索和釋放內存維護的難度還是比較大，不太適合。

2. 定長內存空間分配

   維護兩個列表，一個是未分配內存列表，一個是已分配內存列表。每個內存塊都是一樣大小，分配時如果不夠就將多個塊合併到一起。這種方式的缺點就是會浪費一定的內存空間，如果有特定的場景還是沒有問題。

3. 多段定長池分配

   在上面的定長分配基礎上，由原來的固定一個長度分配空間變為按照不同對象大小(8，16，32，64，128，256，512，1k…64K)，的方式分配多個固定大小的內存池。每次要申請內存的時候按照當前對象大小去對應的池中查找是否有剩餘空間。

   Linux 本身支持動態內存分配和釋放，對應的命令為：malloc/free。malloc 的全稱是 memory allocation，中文叫動態內存分配，用於申請一塊連續的指定大小的內存塊區域以void*類型返回分配的內存區域地址。

   malloc / free的實現過程：

   1. 空閑存儲空間以空閑鏈表的方式組織（地址遞增），每個塊包含一個長度、一個指向下一塊的指針以及一個指向自身存儲空間的指針。（ 因為程序中的某些地方可能不通過 malloc 調用申請，因此 malloc 管理的空間不一定連續）
   2. 當有申請請求時，malloc 會掃描空閑鏈表，直到找到一個足夠大的塊為止（首次適應）(因此每次調用malloc 時並不是花費了完全相同的時間）
   3. 如果該塊恰好與請求的大小相符，則將其從鏈表中移走並返回給用戶。如果該塊太大，則將其分為兩部分，尾部的部分分給用戶，剩下的部分留在空閑鏈表中（更改頭部信息）。因此 malloc 分配的是一塊連續的內存。
   4. 釋放時首先搜索空閑鏈表，找到可以插入被釋放塊的合適位置。如果與被釋放塊相鄰的任一邊是一個空閑塊，則將這兩個塊合為一個更大的塊，以減少內存碎片。

2. Netty 中的內存分配

Netty 採用了 jemalloc 的思想，這是 FreeBSD 實現的一種併發 malloc 的算法。jemalloc 依賴多個 Arena(分配器) 來分配內存，運行中的應用都有固定數量的多個 Arena，默認的數量與處理器的個數有關。系統中有多個 Arena 的原因是由於各個線程進行內存分配時競爭不可避免，這可能會極大的影響內存分配的效率，為了緩解高併發時的線程競爭，Netty 允許使用者創建多個分配器（Arena）來分離鎖，提高內存分配效率。

線程首次分配/回收內存時，首先會為其分配一個固定的 Arena。線程選擇 Arena 時使用 round-robin 的方式，也就是順序輪流選取。

每個線程各種保存 Arena 和緩存池信息，這樣可以減少競爭並提高訪問效率。Arena 將內存分為很多 Chunk 進行管理，Chunk 內部保存 Page，以頁為單位申請。申請內存分配時，會將分配的規格分為幾類：TINY，SAMLL，NORMAL 和 HUGE，分別對應不同的範圍，處理過程也不相同。

tiny 代表了大小在 0-512B 的內存塊；

small 代表了大小在 512B-8K 的內存塊；

normal 代表了大小在 8K-16M 的內存塊；

huge 代表了大於 16M 的內存塊。

每個塊裏面又定義了更細粒度的單位來分配數據：

• Chunk：一個 Chunk 的大小是 16M，Chunk 是 Netty 對操作系統進行內存申請的單位，後續所有的內存分配都是在 Chunk 裏面進行操作。
• Page：Chunk 內部以 Page 為單位分配內存，一個 Page 大小為 8K。當我們需要 16K 的空間時，Netty 就會從一個 Chunk 中找到兩個 Page 進行分配。
• Subpage 和 element：element 是比 Page 更小的單位，當我們申請小於 8K 的內存時，Netty 會以 element 為單位進行內存分配。element 沒有固定大小，具體由用戶的需求決定。Netty 通過 Subpage 管理 element，Subpage 是由 Page 轉變過來的。當我們需要 1K 的空間時，Netty 會把一個 Page 變成 Subpage，然後把 Subpage 分成 8 個 1K 的 element 進行分配。

Chunk 中的內存分配

線程分配內存主要從兩個地方分配: PoolThreadCache 和 Arena。其中 PoolThreadCache 線程獨享, Arena 為幾個線程共享。

初次申請內存的時候，Netty 會從一整塊內存（Chunk）中分出一部分來給用戶使用，這部分工作是由 Arena 來完成。而當用戶使用完畢釋放內存的時候，這些被分出來的內存會按不同規格大小放在 PoolThreadCache 中緩存起來。當下次要申請內存的時候，就會先從 PoolThreadCache 中找。

Chunk、Page、Subpage 和 element 都是 Arena 中的概念，Arena 的工作就是從一整塊內存中分出合適大小的內存塊。Arena 中最大的內存單位是 Chunk，這是 Netty 向操作系統申請內存的單位。而一塊 Chunk（16M） 申請下來之後，內部會被分成 2048 個 Page（8K），當用戶向 Netty 申請超過 8K 內存的時候，Netty 會以 Page 的形式分配內存。

Chunk 內部通過夥伴算法管理 Page，具體實現為一棵完全平衡二叉樹：

二叉樹中所有子節點管理的內存也屬於其父節點。當我們要申請大小為 16K 的內存時，我們會從根節點開始不斷尋找可用的節點，一直到第 10 層。那麼如何判斷一個節點是否可用呢？Netty 會在每個節點內部保存一個值，這個值代表這個節點之下的第幾層還存在未分配的節點。比如第 9 層的節點的值如果為 9，就代表這個節點本身到下面所有的子節點都未分配；如果第 9 層的節點的值為 10，代表它本身不可被分配，但第 10 層有子節點可以被分配；如果第 9 層的節點的值為 12，此時可分配節點的深度大於了總深度，代表這個節點及其下面的所有子節點都不可被分配。下圖描述了分配的過程：

對於小內存（小於4096）的分配還會將 Page 細化成更小的單位 Subpage。Subpage 按大小分有兩大類：

1. Tiny：小於 512 的情況，最小空間為 16，對齊大小為 16，區間為[16,512)，所以共有 32 種情況。
2. Small：大於等於 512 的情況，總共有四種，512,1024,2048,4096。

PoolSubpage 中直接採用位圖管理空閑空間（因為不存在申請 k 個連續的空間），所以申請釋放非常簡單。

第一次申請小內存空間的時候，需要先申請一個空閑頁，然後將該頁轉成 PoolSubpage，再將該頁設為已被佔用，最後再把這個 PoolSubpage 存到 PoolSubpage 池中。這樣下次就不需要再去申請空閑頁了，直接去池中找就好了。Netty 中有 36 種 PoolSubpage，所以用 36 個 PoolSubpage 鏈表表示 PoolSubpage 池。

因為單個 PoolChunk 只有 16M，這遠遠不夠用，所以會很很多很多 PoolChunk，這些 PoolChunk 組成一個鏈表，然後用 PoolChunkList 持有這個鏈表。

我們先從內存分配器 PoolArena 來分析 Netty 中的內存是如何分配的，Area 的工作就是從一整塊內存中協調如何分配合適大小的內存給當前數據使用。PoolArena 是 Netty 的內存池實現抽象類，其內部子類為 HeapArena 和 DirectArena，HeapArena 對應堆內存（heap buffer），DirectArena 對應堆外直接內存(direct buffer)，兩者除了操作的內存（byte[]和ByteBuffer）不同外其餘完全一致。

從結構上來看，PoolArena 中主要包含三部分子內存池：

tinySubpagePools；

smallSubpagePools；

一系列的 PoolChunkList。

tinySubpagePools 和 smallSubpagePools 都是 PoolSubpage 的數組，數組長度分別為 32 和 4。

PoolChunkList 則主要是一個容器，其內部可以保存一系列的 PoolChunk 對象，並且，Netty 會根據內存使用率的不同，將 PoolChunkList 分為不同等級的容器。

abstract class PoolArena<T> implements PoolArenaMetric {

   enum SizeClass {
        Tiny,
        Small,
        Normal
    }
  // 該參數指定了tinySubpagePools數組的長度，由於tinySubpagePools每一個元素的內存塊差值為16，
	// 因而數組長度是512/16，也即這裏的512 >>> 4
  static final int numTinySubpagePools = 512 >>> 4;
	//表示該PoolArena的allocator
  final PooledByteBufAllocator parent;
  //表示PoolChunk中由Page節點構成的二叉樹的最大高度，默認11
  private final int maxOrder;
  //page的大小，默認8K
  final int pageSize;
  // 指定了恭弘=叶 恭弘節點大小8KB是2的多少次冪，默認為13，該字段的主要作用是，在計算目標內存屬於二叉樹的
	// 第幾層的時候，可以藉助於其內存大小相對於pageShifts的差值，從而快速計算其所在層數
  final int pageShifts;
  //默認16MB
  final int chunkSize;
  // 由於PoolSubpage的大小為8KB=8196，因而該字段的值為
	// -8192=>=> 1111 1111 1111 1111 1110 0000 0000 0000
	// 這樣在判斷目標內存是否小於8KB時，只需要將目標內存與該数字進行與操作，只要操作結果等於0，
	// 就說明目標內存是小於8KB的，這樣就可以判斷其是應該首先在tinySubpagePools或smallSubpagePools
	// 中進行內存申請
  final int subpageOverflowMask;
  // 該參數指定了smallSubpagePools數組的長度，默認為4
  final int numSmallSubpagePools;
  //tinySubpagePools用來分配小於512 byte的Page
  private final PoolSubpage<T>[] tinySubpagePools;
  //smallSubpagePools用來分配大於等於512 byte且小於pageSize內存的Page
  private final PoolSubpage<T>[] smallSubpagePools;
  //用來存儲用來分配給大於等於pageSize大小內存的PoolChunk
  //存儲內存利用率50-100%的chunk
  private final PoolChunkList<T> q050;
  //存儲內存利用率25-75%的chunk
  private final PoolChunkList<T> q025;
  //存儲內存利用率1-50%的chunk
  private final PoolChunkList<T> q000;
  //存儲內存利用率0-25%的chunk
  private final PoolChunkList<T> qInit;
  //存儲內存利用率75-100%的chunk
  private final PoolChunkList<T> q075;
  //存儲內存利用率100%的chunk
  private final PoolChunkList<T> q100;
	//堆內存(heap buffer)
  static final class HeapArena extends PoolArena<byte[]> {
  
  }
   //堆外直接內存(direct buffer)
  static final class DirectArena extends PoolArena<ByteBuffer> {
    
  }
  
  
}

如上所示，PoolArena 是由多個 PoolChunk 組成的大塊內存區域，而每個 PoolChun k則由多個 Page 組成。當需要分配的內存小於 Page 的時候，為了節約內存採用 PoolSubpage 實現小於 Page 大小內存的分配。在PoolArena 中為了保證 PoolChunk 空間的最大利用化，按照 PoolArena 中各 個PoolChunk 已使用的空間大小將其劃分為 6 類：

1. qInit：存儲內存利用率 0-25% 的 chunk；
2. q000：存儲內存利用率 1-50% 的 chunk；
3. q025：存儲內存利用率 25-75% 的 chunk；
4. q050：存儲內存利用率 50-100% 的 chunk；
5. q075：存儲內存利用率 75-100%的 chunk；
6. q100：存儲內存利用率 100%的 chunk。

PoolArena 維護了一個 PoolChunkList 組成的雙向鏈表，每個 PoolChunkList 內部維護了一個 PoolChunk 雙向鏈表。分配內存時，PoolArena 通過在 PoolChunkList 找到一個合適的 PoolChunk，然後從 PoolChunk 中分配一塊內存。

下面來看 PoolArena 是如何分配內存的：

private void allocate(PoolThreadCache cache, PooledByteBuf<T> buf, final int reqCapacity) {
  // 將需要申請的容量格式為 2^N
  final int normCapacity = normalizeCapacity(reqCapacity);
  // 判斷目標容量是否小於8KB，小於8KB則使用tiny或small的方式申請內存
  if (isTinyOrSmall(normCapacity)) { // capacity < pageSize
    int tableIdx;
    PoolSubpage<T>[] table;
    boolean tiny = isTiny(normCapacity);
    // 判斷目標容量是否小於512字節，小於512字節的為tiny類型的
    if (tiny) { // < 512
      // 將分配區域轉移到 tinySubpagePools 中
      if (cache.allocateTiny(this, buf, reqCapacity, normCapacity)) {
        // was able to allocate out of the cache so move on
        return;
      }
      // 如果無法從當前線程緩存中申請到內存，則嘗試從tinySubpagePools中申請，這裏tinyIdx()方法
      // 就是計算目標內存是在tinySubpagePools數組中的第幾號元素中的
      tableIdx = tinyIdx(normCapacity);
      table = tinySubpagePools;
    } else {
      // 如果目標內存在512byte~8KB之間，則嘗試從smallSubpagePools中申請內存。這裏首先從
      // 當前線程的緩存中申請small級別的內存，如果申請到了，則直接返回
      if (cache.allocateSmall(this, buf, reqCapacity, normCapacity)) {
        // was able to allocate out of the cache so move on
        return;
      }
      tableIdx = smallIdx(normCapacity);
      table = smallSubpagePools;
    }
		// 獲取目標元素的頭結點
    final PoolSubpage<T> head = table[tableIdx];

    // 這裏需要注意的是，由於對head進行了加鎖，而在同步代碼塊中判斷了s != head，
    // 也就是說PoolSubpage鏈表中是存在未使用的PoolSubpage的，因為如果該節點已經用完了，
    // 其是會被移除當前鏈表的。也就是說只要s != head，那麼這裏的allocate()方法
    // 就一定能夠申請到所需要的內存塊
    synchronized (head) {
      // s != head就證明當前PoolSubpage鏈表中存在可用的PoolSubpage，並且一定能夠申請到內存，
      // 因為已經耗盡的PoolSubpage是會從鏈表中移除的
      final PoolSubpage<T> s = head.next;
      // 如果此時 subpage 已經被分配過內存了執行下文，如果只是初始化過，則跳過該分支
      if (s != head) {
        // 從PoolSubpage中申請內存
        assert s.doNotDestroy && s.elemSize == normCapacity;
        // 通過申請的內存對ByteBuf進行初始化
        long handle = s.allocate();
        assert handle >= 0;
        // 初始化 PoolByteBuf 說明其位置被分配到該區域，但此時尚未分配內存
        s.chunk.initBufWithSubpage(buf, handle, reqCapacity);
				// 對tiny類型的申請數進行更新
        if (tiny) {
          allocationsTiny.increment();
        } else {
          allocationsSmall.increment();
        }
        return;
      }
    }
    // 走到這裏，說明目標PoolSubpage鏈表中無法申請到目標內存塊，因而就嘗試從PoolChunk中申請
    allocateNormal(buf, reqCapacity, normCapacity);
    return;
  }
   // 走到這裏說明目標內存是大於8KB的，那麼就判斷目標內存是否大於16M，如果大於16M，
  // 則不使用內存池對其進行管理，如果小於16M，則到PoolChunkList中進行內存申請
  if (normCapacity <= chunkSize) {
    // 小於16M，首先到當前線程的緩存中申請，如果申請到了則直接返回，如果沒有申請到，
    // 則到PoolChunkList中進行申請
    if (cache.allocateNormal(this, buf, reqCapacity, normCapacity)) {
      // was able to allocate out of the cache so move on
      return;
    }
    allocateNormal(buf, reqCapacity, normCapacity);
  } else {
    // 對於大於16M的內存，Netty不會對其進行維護，而是直接申請，然後返回給用戶使用
    allocateHuge(buf, reqCapacity);
  }
}

所有內存分配的 size 都會經過 normalizeCapacity() 進行處理，申請的容量總是會被格式為 2^N。主要規則如下：

1. 如果目標容量小於 16 字節，則返回 16；
2. 如果目標容量大於 16 字節，小於 512 字節，則以 16 字節為單位，返回大於目標字節數的第一個 16 字節的倍數。比如申請的 100 字節，那麼大於 100 的 16 整數倍最低為： 16 * 7 = 112，因而返回 112；
3. 如果目標容量大於 512 字節，則返回大於目標容量的第一個 2 的指數冪。比如申請的 1000 字節，那麼返回的將是：2^10 = 1024。

PoolArena 提供了兩種方式進行內存分配：

1. PoolSubpage 用於分配小於 8k 的內存

   • tinySubpagePools：用於分配小於 512 字節的內存，默認長度為 32，因為內存分配最小為 16，每次增加16，直到512，區間[16，512)一共有 32 個不同值；
   • smallSubpagePools：用於分配大於等於 512 字節的內存，默認長度為 4；

• tinySubpagePools 和 smallSubpagePools 中的元素默認都是 subpage。

1. poolChunkList 用於分配大於 8k 的內存

   上面已經解釋了 q 開頭的幾個變量用於保存大於 8k 的數據。

默認先嘗試從 poolThreadCache 中分配內存，PoolThreadCache 利用 ThreadLocal 的特性，消除了多線程競爭，提高內存分配效率；

首次分配時，poolThreadCache 中並沒有可用內存進行分配，當上一次分配的內存使用完並釋放時，會將其加入到 poolThreadCache 中，提供該線程下次申請時使用。

如果是分配小內存，則嘗試從 tinySubpagePools 或 smallSubpagePools 中分配內存，如果沒有合適 subpage，則採用方法 allocateNormal 分配內存。

如果分配一個 page 以上的內存，直接採用方法 allocateNormal() 分配內存，allocateNormal()則會將申請動作交由 PoolChunkList 進行。

private synchronized void allocateNormal(PooledByteBuf<T> buf, int reqCapacity, int normCapacity) {
  //如果在對應的PoolChunkList能申請到內存，則返回
  if (q050.allocate(buf, reqCapacity, normCapacity) || q025.allocate(buf, reqCapacity, normCapacity) ||
      q000.allocate(buf, reqCapacity, normCapacity) || qInit.allocate(buf, reqCapacity, normCapacity) ||
      q075.allocate(buf, reqCapacity, normCapacity)) {
    ++allocationsNormal;
    return;
  }

  // Add a new chunk.
  PoolChunk<T> c = newChunk(pageSize, maxOrder, pageShifts, chunkSize);
  long handle = c.allocate(normCapacity);
  ++allocationsNormal;
  assert handle > 0;
  c.initBuf(buf, handle, reqCapacity);
  qInit.add(c);
}

首先將申請動作按照 q050->q025->q000->qInit->q075 的順序依次交由各個 PoolChunkList 進行處理，如果在對應的 PoolChunkList 中申請到了內存，則直接返回。

如果申請不到，那麼直接創建一個新的 PoolChunk，然後在該 PoolChunk 中申請目標內存，最後將該 PoolChunk 添加到 qInit 中。

上面說過 Chunk 是 Netty 向操作系統申請內存塊的最大單位，每個 Chunk 是16M，PoolChunk 內部通過 memoryMap 數組維護了一顆完全平衡二叉樹作為管理底層內存分佈及回收的標記位，所有的子節點管理的內存也屬於其父節點。

關於 PoolChunk 內部如何維護完全平衡二叉樹就不在這裏展開，大家有興趣可以自行看源碼。

對於內存的釋放，PoolArena 主要是分為兩種情況，即池化和非池化，如果是非池化，則會直接銷毀目標內存塊，如果是池化的，則會將其添加到當前線程的緩存中。如下是 free()方法的源碼：

public void free(PoolChunk<T> chunk, ByteBuffer nioBuffer, long handle, int normCapacity,
     PoolThreadCache cache) {
  // 如果是非池化的，則直接銷毀目標內存塊，並且更新相關的數據
  if (chunk.unpooled) {
    int size = chunk.chunkSize();
    destroyChunk(chunk);
    activeBytesHuge.add(-size);
    deallocationsHuge.increment();
  } else {
    // 如果是池化的，首先判斷其是哪種類型的，即tiny，small或者normal，
    // 然後將其交由當前線程的緩存進行處理，如果添加成功，則直接返回
    SizeClass sizeClass = sizeClass(normCapacity);
    if (cache != null && cache.add(this, chunk, nioBuffer, handle,
          normCapacity, sizeClass)) {
      return;
    }

    // 如果當前線程的緩存已滿，則將目標內存塊返還給公共內存塊進行處理
    freeChunk(chunk, handle, sizeClass, nioBuffer);
  }
}

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

【其他文章推薦】

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

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

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

※超省錢租車方案

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

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

長話短說，今天分享我為前後端分離項目搭建Gitlab CI/CD流程的一些額外經驗。

Before

Gitlab-ci是Gitlab提供的CI/CD特性，結合Gitlab簡單友好的配置界面，能愉悅的在Gitlab界面查看管道執行流程，並自然流暢的推動敏捷開發流程。
Gitlab-CI/CD的核心是搭建Gitlab Runner、編寫.gitlab-ci.yaml文件。
詳細示例請參考：Gitlab CI/CD+ASP.NETCore.

本次前後端兩個項目使用同一個Gitlab Runner(shell模式)，前端項目的gitlab-ci.yaml構建Job如圖：

Round 1

單個Gitlab Runner可為多個項目提供構建服務，

gitlab-Runner register命令只能接受一個註冊token，當時為支持多個項目，花了不少冤枉心思倒騰Gitlab Runner.

你可以為註冊的項目解鎖Runner，這樣Girlab Runner就可以為其他項目提供構建：

Round 2

使用Runner緩存加快前端構建過程
大家都知道npm_module被前端開發者詬病為毒瘤， 而Gitlab runner執行每次構建job之前都會清場，pull/fetch指定的代碼再執行job, 這就導致每次build job會耗時很久(要拉取毒瘤)。

#!/bin/bash

cd   packages/event-analysis
yarn config set registry http://registry.npm.gridsum.com &&  yarn --prefer-offline --frozen-lockfile
npm run build

以上是build任務的腳本frontend.sh，總耗時3m33s，其中yarn命令拉取npm_modules耗時172.52s

gitlab runner支持緩存
在.gitlab-ci.yaml 文件中定義cache指令:
cache被用來在job之間緩存文件，更強大的是可以定義文件依賴緩存：

build:
  stage: build
  cache:
    key:
      files:
        - packages/event-analysis/package.json
    paths:
      - node_modules
  script: 
    - ./frontend.sh
  tags:
    - my-tag

緩存key是yarn命令要用到的package.json，緩存內容是npm_modules;
只要這個package.json文件未變更，後續任務就會使用緩存的npm_modules，而不用重建npm_modules依賴。

使用runner緩存優化后build任務總耗時1m18s，其中yarn命令耗時22.83s:

以上針對Gitlab-CI的使用經驗點到為止，足夠應對我當前項目，更多請關注：

Reference

1. https://docs.gitlab.com/ee/ci/runners/#prevent-a-specific-runner-from-being-enabled-for-other-projects
2. https://docs.gitlab.com/ee/ci/caching/

Devops的圈子很大，上面的Gitlab-ci也只是點到為止，應付我當前的前後端分離項目.. 歡迎大家來捶我。

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

【其他文章推薦】

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

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

※超省錢租車方案

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

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

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

事件背景

之前做過幾個主題，但是都有些看膩了，然後就想着啥時候重構一下，於是就有了現在的新樣式：

https://github.com/KU4NG/CNBLOG-Theme-Light

當然，如果你對之前的感興趣，也可以查看之前的分享：

https://github.com/KU4NG/CNBlog-Theme

裡面包含幾個主題，但是我是有些懶得維護了，太忙了，感興趣的自己去改改 CSS 就行了！

新主題配置方法

1. 基礎配置：

前往博客園設置頁面，就行配置，需要注意的是：

a. 博客標題就是最終你博客的 logo，所以選你喜歡的。

b. 我博客標題中的來自 windows 10 系統輸入法旁邊的表情。

c. 基礎主題選：SimpleMemory，這一步很重要，因為我得樣式都是根據該主題的 HTML 結構寫的。

2. 配置樣式：

將本文中提供的 CSS 代碼或者 github 上面 css 目錄下 style.css 文件中的內容粘貼到此處。

*{margin:0;padding:0;font-weight:normal;letter-spacing:1.5px;font-family:PingFangSC-Regular,HelveticaNeue-Light,'Helvetica Neue Light','Microsoft YaHei',sans-serif,Simsun}div{border-radius:0!important}a{text-decoration:none!important}a:link{text-decoration:none!important}a:visited{text-decoration:none!important}a:hover{text-decoration:none!important}a:active{text-decoration:none!important}body{background-color:#eee}#header{min-width:1200px;height:50px;width:100%;display:block;background-color:white;box-shadow:0 1px 2px 0 rgba(0,0,0,.05)}#header *{color:#333!important}#header h1{float:left;width:200px;padding-left:20px}#header h1 a{height:46px;line-height:46px;font-size:18px!important;font-weight:bolder!important;letter-spacing:3px!important}#header #lnkBlogLogo{display:none}#header h2{display:none}#header li{list-style:none;float:right;height:50px;line-height:50px;position:relative}#header li:hover{cursor:pointer}#header li a{font-size:12px;letter-spacing:2px;padding:0 20px}#header li a::before,#header li a::after{position:absolute;top:0;right:0;bottom:0;left:0;content:'';opacity:0;pointer-events:none;-webkit-transition:opacity .4s,-webkit-transform .4s;transition:opacity .4s,transform .4s}#header li a::before{border-top:2px solid #333;-webkit-transform:scale(0,1);transform:scale(0,1)}#header li:hover a::before,#header li:hover a::after{opacity:1;-webkit-transform:scale(1);transform:scale(1)}#header .blogStats{display:none}#header #navigator{margin-right:200px}#sidebar_search{display:block;width:200px;position:absolute;top:0;right:0;height:48px;line-height:48px}#sidebar_search h3{display:none}#sidebar_search .div_my_zzk{margin-top:0;margin-bottom:0}#sidebar_search .input_my_zzk{display:inline-block;vertical-align:middle;padding:0 10px;border:0;cursor:text;font-size:12px}#sidebar_search .btn_my_zzk{background-color:#009688;color:#fff!important;white-space:nowrap;text-align:center;cursor:pointer;padding-left:10px;padding-right:10px}#sidebar_search input:focus{outline:0}#sidebar_search input{outline:0;border:0}#main{width:1200px;margin:10px auto}#main #mainContent{width:960px;background-color:white;padding:20px;float:left}#main #mainContent .day{position:relative;border:1px dashed lightgrey;padding:15px;margin:0 0 15px 0}#main #mainContent .day .dayTitle{position:absolute;top:-1px;right:-1px;background-color:#eee;width:110px;text-align:right;padding:0 10px 3px 10px}#main #mainContent .day .dayTitle a{font-size:12px;color:#333;opacity:.6}#main #mainContent .day .postTitle a{position:relative;left:-18px;border-left:4px solid #dc3545;padding-left:20px;font-size:18px;font-weight:bolder!important;color:#333}#main .postTitle span{font-weight:bolder!important}#main #mainContent .day .postTitle a:hover{color:#036}#main #mainContent .day .postCon{padding:10px}#main #mainContent .day .postCon .c_b_p_desc{font-size:12px;letter-spacing:2px;opacity:.6;line-height:2;width:900px;overflow:hidden;white-space:nowrap;text-overflow:ellipsis}#main #mainContent .day .postDesc{font-size:12px;opacity:.6;text-align:right}#main #mainContent .day .postDesc a{font-size:12px;color:#dc3545}#main #mainContent .day .postSeparator{height:15px;border-top:1px dashed lightgrey;border-bottom:1px dashed lightgrey;border-left:2px solid white;border-right:2px solid white;margin:15px -17px}#main #mainContent #nav_next_page a{font-size:12px;color:#333}#main #mainContent .topicListFooter{margin-right:0}#main #mainContent .pager{font-size:12px;color:#dc3545;text-align:right}#main #mainContent .pager a{font-size:12px;color:gray;border:1px solid lightgray}#main #mainContent #homepage_top_pager{display:none}#sideBar{width:200px;float:right}#sideBar #sideBarMain{width:190px;float:right}#sideBar #sideBarMain *{color:#333;font-size:12px;letter-spacing:2px}#sideBar #sideBarMain #sidebar_news{background-color:white}#sideBar #sideBarMain #sidebar_news h3{background-color:#dc3545;color:white;border-bottom:1px solid #eee;padding:5px 15px;font-size:14px}#sideBar #sideBarMain #sidebar_news #blog-news{padding:15px 15px 0 15px}#sideBar #sideBarMain #sidebar_news #blog-news *{line-height:25px}#sideBar #sideBarMain #sidebar_news #blog-news #profile_block{margin-top:0}#sideBar #sideBarMain #sidebar_categories{background-color:white}#sideBar #sideBarMain #sidebar_categories h3{padding:20px 15px 5px 15px}#sideBar #sideBarMain #sidebar_categories ul{list-style:none;counter-reset:headings;padding:0 15px 15px 15px}#sideBar #sideBarMain #sidebar_categories ul li{line-height:30px;border-bottom:1px dashed #eee}#sideBar #sideBarMain #sidebar_categories ul li:before{counter-increment:headings;content:counter(headings,decimal) ".";font-family:"Bree Serif",serif}#sideBar #sideBarMain #sidebar_categories ul li a{letter-spacing:1px}#sideBar #sideBarMain #sidebar_categories ul li a:hover{color:#dc3545}#footer{font-size:12px;text-align:center;line-height:25px;margin-top:20px;margin-bottom:20px;color:#036}
#footer br{display:none}#main #mainContent .entrylist h1{font-size:18px;font-weight:bolder;text-align:center;margin-top:15px;margin-bottom:30px}#main #mainContent .entrylistItem{position:relative;border:1px dashed lightgrey;padding:15px;margin:0 0 15px 0}#main #mainContent .entrylistItem .entrylistPosttitle a{position:relative;left:-18px;border-left:4px solid #dc3545;padding-left:20px;font-size:18px;font-weight:bolder;color:#333}#main #mainContent .entrylistItem .entrylistPosttitle a:hover{color:#036}#main .entrylistPosttitle span{font-weight:bolder}#main #mainContent .entrylistItem .entrylistPostSummary{padding:10px}#main #mainContent .entrylistItem .entrylistPostSummary .c_b_p_desc{font-size:12px;letter-spacing:2px;opacity:.6;line-height:2;width:900px;overflow:hidden;white-space:nowrap;text-overflow:ellipsis}#main #mainContent .entrylistItem .entrylistItemPostDesc{font-size:12px;opacity:.6;text-align:right}#main #mainContent .entrylistItem .entrylistItemPostDesc a{font-size:12px;color:#dc3545}#main #post_detail{padding:30px;position:relative}#main #post_detail .postTitle{padding:0 0 50px 0;text-align:center;border-bottom:1px dotted #ccc}#main #post_detail .postTitle a{font-size:20px;color:#333;font-weight:bolder}#main #post_detail .postDesc{position:absolute;width:calc(100% - 60px);top:85px;text-align:center}#main #post_detail .postDesc{font-size:12px;line-height:25px;color:#333;opacity:.7}#main #post_detail .postDesc *{font-size:12px;color:#333;opacity:.7}#main #post_detail .postBody #cnblogs_post_body{margin-top:30px;padding:15px}#main #post_detail .postBody #cnblogs_post_body p,#main #post_detail .postBody #cnblogs_post_body span{letter-spacing:1.5px;line-height:30px;font-size:14px;font-family:SimHei;margin:0;opacity:.9}#main #post_detail .postBody #cnblogs_post_body img{margin:15px 0;max-width:880px}#main #post_detail .postBody #cnblogs_post_body table{width:100%;margin:15px 0}#main #post_detail .postBody #cnblogs_post_body table *{font-size:12px}#main #post_detail .postBody #cnblogs_post_body table th{padding:6px 10px!important;text-align:left;background-color:#1c2b36;color:white;border-color:#1c2b36}#main #post_detail .postBody #cnblogs_post_body table td{padding:6px 10px!important;text-align:left}#main #post_detail .postBody #cnblogs_post_body .cnblogs_code{padding:15px 20px;border:0}#main #post_detail .postBody #cnblogs_post_body .cnblogs_code_toolbar{display:none}#main #post_detail .postBody #cnblogs_post_body blockquote{border:0;background-color:#eee;border-left:5px solid #009688}#main #post_detail .postBody #cnblogs_post_body blockquote *{font-size:12px;color:#333}#main #post_detail .postBody #blog_post_info_block{padding:15px}#main #post_detail .postBody #blog_post_info_block *{font-size:12px;color:#333}#main #post_detail .postBody #blog_post_info_block #author_profile_info{display:none}#main #post_detail .postBody #blog_post_info_block #author_profile_detail{display:none}#main #post_detail .postBody #blog_post_info_block #blog_post_info #green_channel{float:left;border:0}#main #post_detail .postBody #blog_post_info_block #blog_post_info #div_digg{float:right}#main #comment_form{padding:45px!important}#main #comment_form *{font-size:12px}#main #comment_form .comment_textarea{width:100%}#main #blog-comments-placeholder{padding:0 45px!important}#main #blog-comments-placeholder *{font-size:12px;color:#333}#main #blog-comments-placeholder .feedbackItem{padding:15px 0;border-bottom:1px dashed #eee}#main #blog-comments-placeholder .feedbackListSubtitle{line-height:30px}#main #blog-comments-placeholder a{color:#009688}#main #blog-comments-placeholder div{line-height:30px}#main #blog-comments-placeholder .feedbackManage{float:right}#main #blog-comments-placeholder .feedbackListSubtitle .layer{color:#036;font-weight:bolder}#main #blog-comments-placeholder .feedbackListSubtitle .louzhu{color:white;background-color:#1c2b36;padding:0 10px;margin:0 -8px}#main #blog-comments-placeholder br{display:none;padding-left:20px}#main #commentbox_opt #btn_comment_submit{background-color:#009688;color:#fff!important;white-space:nowrap;text-align:center;cursor:pointer;padding-left:10px;padding-right:10px;border:0;width:auto}#main #commentbox_opt a{color:#dc3545}.my-title{font-size:18px!important;font-weight:bolder;font-family:simsun!important;border-left:5px solid #dc3545;padding-left:10px;line-height:20px!important;position:relative;left:-15px}#comment_nav{display:none}#ad_t2{display:none}.c_ad_block{display:none}#under_post_news{display:none}

注意，一定要選擇禁用默認的樣式，否則可能樣式衝突！ 

3. 配置側邊欄：

代碼如下：

<div style="width: 100%;text-align: center;">
    <img style="border-radius: 50%;border: 1px solid #eee;" src="https://pic.cnblogs.com/face/979767/20180915094029.png" alt="">
</div>
<div>聯繫： Q-1214966109</div>

值得注意的是：

a. 頭像的連接可以在自己的博客中找到，如： 

b. 聯繫方式可以寫自己，如果你還需要其它項目，繼續添加 div 即可！

最終的效果就是我的效果：

4. 配置首頁按鈕和 GITHUB 鏈接：

代碼如下：

<script>
    // 菜單新加標籤
    var indexEle = '<li><a target="_blank" class="menu" href="https://www.cnblogs.com/Dy1an">首頁</a></li>';
    var githubEle = '<li><a target="_blank" class="menu" href="https://github.com/KU4NG">GITHUB</a></li><li><a target="_blank" class="menu" href="https://github.com/KU4NG">主題</a></li>';
    document.getElementById('navList').insertAdjacentHTML("beforeEnd", indexEle);
    document.getElementById('navList').insertAdjacentHTML("afterBegin", githubEle);
</script>

需要注意的是：

a. 首頁鏈接記得換成自己的，當然你要是直接用我的我也是不會介意的。

b. GITHUB 你可以選擇換成其它的自己的一些資源。

c. 主題鏈接建議不要去掉，這裏吸波粉，讓我看到到底有多少人是支持這個項目的！

最終效果如下：

5. 配置搜索框：

這裏沒有需要修改的，直接粘貼就行，代碼如下：

<script>
    window.onload =  function() {
        var ele = document.getElementById('q');
        console.log(ele);
        ele.setAttribute("placeholder","搜索相關博客...");
        ele.setAttribute("autocomplete","off");
    }
</script>

最終效果：

已知問題：

由於網絡原因可能導致沒有加載或者加載不完全，刷新頁面即可！

6. 配置菜單：

想要以我的博客效果显示，則需要配置菜單：

在選項配置中選擇配置！

特殊用法說明 

1. 段落標題：

文中出現段落標題需要瘦動修改 HTML：

增加樣式：

代碼：

class="my-title"

2. 表格：

表格同樣需要以 html 格式插入：

<table>
    <thead>
        <th>
            <td>標題</td>
            <td>標題</td>
            <td>標題</td>
        </th>
    </thead>
    <tbody>
        <tr>
            <td>數據行</td>
            <td>數據行</td>
            <td>數據行</td>
        </tr>
        <tr>
            <td>數據行</td>
            <td>數據行</td>
            <td>數據行</td>
        </tr>
    </tbody>
</table>

效果如下：

3. 圖片：

最後就是截圖，文中的截圖建議大小不超過 870px，865px最佳，否則圖片會壓縮，影響體驗！

意見和建議

最後就是幾點說明：

1. 如果遇到樣式問題，歡迎反饋，QQ，留言，GITHUB 都可以。

2. 如果覺得可以，可以去 GITHUB star 支持一下，也可以在本文中頂一下！ 

3. 最後吹一波博客園！

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

【其他文章推薦】

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

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

※回頭車貨運收費標準

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

※超省錢租車方案

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