本篇已加入《》，可以點擊查看更多容器化技術相關係列文章。上一篇《》中介紹了Docker自帶的logs子命令以及其Logging driver，本篇將會介紹一個流行的開源日誌管理方案ELK。

一、關於ELK

1.1 ELK簡介

　　ELK 是Elastic公司提供的一套完整的日誌收集以及展示的解決方案，是三個產品的首字母縮寫，分別是ElasticSearch、Logstash 和 Kibana。

• Elasticsearch是實時全文搜索和分析引擎，提供搜集、分析、存儲數據三大功能
• Logstash是一個用來搜集、分析、過濾日誌的工具
• Kibana是一個基於Web的圖形界面，用於搜索、分析和可視化存儲在 Elasticsearch指標中的日誌數據 　　

1.2 ELK日誌處理流程

 　　上圖展示了在Docker環境下，一個典型的ELK方案下的日誌收集處理流程：

• Logstash從各個Docker容器中提取日誌信息
• Logstash將日誌轉發到ElasticSearch進行索引和保存
• Kibana負責分析和可視化日誌信息

　　由於Logstash在數據收集上並不出色，而且作為Agent，其性能並不達標。基於此，Elastic發布了beats系列輕量級採集組件。

　　這裏我們要實踐的Beat組件是Filebeat，Filebeat是構建於beats之上的，應用於日誌收集場景的實現，用來替代 Logstash Forwarder 的下一代 Logstash 收集器，是為了更快速穩定輕量低耗地進行收集工作，它可以很方便地與 Logstash 還有直接與 Elasticsearch 進行對接。

　　本次實驗直接使用Filebeat作為Agent，它會收集我們在第一篇《》中介紹的json-file的log文件中的記錄變動，並直接將日誌發給ElasticSearch進行索引和保存，其處理流程變為下圖，你也可以認為它可以稱作 EFK。

二、ELK套件的安裝

　　本次實驗我們採用Docker方式部署一個最小規模的ELK運行環境，當然，實際環境中我們或許需要考慮高可用和負載均衡。

　　首先拉取一下sebp/elk這個集成鏡像，這裏選擇的tag版本是640（最新版本已經是7XX了）：

docker pull sebp/elk:640

　　注：由於其包含了整個ELK方案，所以需要耐心等待一會。

　　通過以下命令使用sebp/elk這個集成鏡像啟動運行ELK：

docker run -it -d --name elk \
    -p 5601:5601 \
    -p 9200:9200 \
    -p 5044:5044 \
    sebp/elk:640

　　運行完成之後就可以先訪問一下 http://[Your-HostIP]:5601 看看Kibana的效果：　　

　　Kibana管理界面

Kibana Index Patterns界面

　　當然，目前沒有任何可以显示的ES的索引和數據，再訪問一下http://[Your-HostIP]:9200 看看ElasticSearch的API接口是否可用：

ElasticSearch API

　　Note：如果啟動過程中發現一些錯誤，導致ELK容器無法啟動，可以參考《》及《》一文。如果你的主機內存低於4G，建議增加配置設置ES內存使用大小，以免啟動不了。例如下面增加的配置，限制ES內存使用最大為1G：

docker run -it -d --name elk \
    -p 5601:5601 \
    -p 9200:9200 \
    -p 5044:5044 \
 　　-e ES_MIN_MEM=512m \
    -e ES_MAX_MEM=1024m \
    sebp/elk:640

三、Filebeat配置

3.1 安裝Filebeat

　　這裏我們通過rpm的方式下載Filebeat，注意這裏下載和我們ELK對應的版本（ELK是6.4.0，這裏也是下載6.4.0，避免出現錯誤）：

wget https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-6.4.0-x86_64.rpm
rpm -ivh filebeat-6.4.0-x86_64.rpm

3.2 配置Filebeat　　

 　　這裏我們需要告訴Filebeat要監控哪些日誌文件 及 將日誌發送到哪裡去，因此我們需要修改一下Filebeat的配置：

cd /etc/filebeat
vim filebeat.yml

　　要修改的內容為：

　　（1）監控哪些日誌？

filebeat.inputs:

# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.

- type: log

  # Change to true to enable this input configuration.
  enabled: true

  # Paths that should be crawled and fetched. Glob based paths.
  paths:
    - /var/lib/docker/containers/*/*.log - /var/log/syslog

　　這裏指定paths：/var/lib/docker/containers/*/*.log，另外需要注意的是將 enabled 設為 true。

　　（2）將日誌發到哪裡？

#-------------------------- Elasticsearch output ------------------------------
output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["192.168.16.190:9200"]

  # Optional protocol and basic auth credentials.
  #protocol: "https"
  #username: "elastic"
  #password: "changeme"

　　這裏指定直接發送到ElasticSearch，配置一下ES的接口地址即可。

　　Note：如果要發到Logstash，請使用後面這段配置，將其取消註釋進行相關配置即可：

#----------------------------- Logstash output --------------------------------
#output.logstash:
  # The Logstash hosts
  #hosts: ["localhost:5044"]

  # Optional SSL. By default is off.
  # List of root certificates for HTTPS server verifications
  #ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]

  # Certificate for SSL client authentication
  #ssl.certificate: "/etc/pki/client/cert.pem"

  # Client Certificate Key
  #ssl.key: "/etc/pki/client/cert.key"

3.3 啟動Filebeat

　　由於Filebeat在安裝時已經註冊為systemd的服務，所以只需要直接啟動即可：

systemctl start filebeat.service

　　檢查Filebeat啟動狀態：

systemctl status filebeat.service

3.4 驗證Filebeat

　　通過訪問ElasticSearch API可以發現以下變化：ES建立了以filebeat-開頭的索引，我們還能夠看到其來源及具體的message。

四、Kibana配置

　　接下來我們就要告訴Kibana，要查詢和分析ElasticSearch中的哪些日誌，因此需要配置一個Index Pattern。從Filebeat中我們知道Index是filebeat-timestamp這種格式，因此這裏我們定義Index Pattern為 filebeat-*

　　點擊Next Step，這裏我們選擇Time Filter field name為@timestamp：

　　單擊Create index pattern按鈕，即可完成配置。

　　這時我們單擊Kibana左側的Discover菜單，即可看到容器的日誌信息啦：

　　仔細看看細節，我們關注一下message字段：

　　可以看到，我們重點要關注的是message，因此我們也可以篩選一下只看這個字段的信息：

　　此外，Kibana還提供了搜索關鍵詞的日誌功能，例如這裏我關注一下日誌中包含unhandled exception（未處理異常）的日誌信息：

　　這裏只是樸素的展示了導入ELK的日誌信息，實際上ELK還有很多很豐富的玩法，例如分析聚合、炫酷Dashboard等等。筆者在這裏也是初步使用，就介紹到這裏啦。

五、Fluentd引入

5.1 關於Fluentd

　　前面我們採用的是Filebeat收集Docker的日誌信息，基於Docker默認的json-file這個logging driver，這裏我們改用Fluentd這個開源項目來替換json-file收集容器的日誌。

　　Fluentd是一個開源的數據收集器，專為處理數據流設計，使用JSON作為數據格式。它採用了插件式的架構，具有高可擴展性高可用性，同時還實現了高可靠的信息轉發。Fluentd也是雲原生基金會 (CNCF) 的成員項目之一，遵循Apache 2 License協議，其github地址為：。Fluentd與Logstash相比，比佔用內存更少、社區更活躍，兩者的對比可以參考這篇文章《》。

　　因此，整個日誌收集與處理流程變為下圖，我們用 Filebeat 將 Fluentd 收集到的日誌轉發給 Elasticsearch。

 　　當然，我們也可以使用Fluentd的插件（fluent-plugin-elasticsearch）直接將日誌發送給 Elasticsearch，可以根據自己的需要替換掉Filebeat，從而形成Fluentd => ElasticSearch => Kibana 的架構，也稱作EFK。

5.2 運行Fluentd

　　這裏我們通過容器來運行一個Fluentd採集器：

docker run -d -p 24224:24224 -p 24224:24224/udp -v /edc/fluentd/log:/fluentd/log fluent/fluentd

　　默認Fluentd會使用24224端口，其日誌會收集在我們映射的路徑下。

　　此外，我們還需要修改Filebeat的配置文件，將/edc/fluentd/log加入監控目錄下：

#=========================== Filebeat inputs =============================

filebeat.inputs:

# Each - is an input. Most options can be set at the input level, so
# you can use different inputs for various configurations.
# Below are the input specific configurations.

- type: log

  # Change to true to enable this input configuration.
  enabled: true

  # Paths that should be crawled and fetched. Glob based paths.
  paths:
    - /edc/fluentd/log/*.log

　　添加監控配置之後，需要重新restart一下filebeat：

systemctl restart filebeat

5.3 運行測試容器

　　為了驗證效果，這裏我們Run兩個容器，並分別制定其log-dirver為fluentd：

docker run -d \
           --log-driver=fluentd \
           --log-opt fluentd-address=localhost:24224 \
           --log-opt tag="test-docker-A" \
           busybox sh -c 'while true; do echo "This is a log message from container A"; sleep 10; done;'

docker run -d \
           --log-driver=fluentd \
           --log-opt fluentd-address=localhost:24224 \
           --log-opt tag="test-docker-B" \
           busybox sh -c 'while true; do echo "This is a log message from container B"; sleep 10; done;'

　　這裏通過指定容器的log-driver，以及為每個容器設立了tag，方便我們後面驗證查看日誌。

5.4 驗證EFK效果

　　這時再次進入Kibana中查看日誌信息，便可以通過剛剛設置的tag信息篩選到剛剛添加的容器的日誌信息了：

六、小結

　　本文從ELK的基本組成入手，介紹了ELK的基本處理流程，以及從0開始搭建了一個ELK環境，演示了基於Filebeat收集容器日誌信息的案例。然後，通過引入Fluentd這個開源數據收集器，演示了如何基於EFK的日誌收集案例。當然，ELK/EFK有很多的知識點，筆者也還只是初步使用，希望未來能夠分享更多的實踐總結。

參考資料

CloudMan，《》

一杯甜酒，《》

於老三，《》

zpei0411，《》

曹林華，《》

作者：

出處：

本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接。

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

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

摘要：

本文演示如何向有效用戶提供jwt，以及如何在webapi中使用該token通過JwtBearerMiddleware中間件對用戶進行身份認證。

認證和授權區別？

首先我們要弄清楚認證（Authentication）和授權（Authorization）的區別，以免混淆了。認證是確認的過程中你是誰，而授權圍繞是你被允許做什麼，即權限。顯然，在確認允許用戶做什麼之前，你需要知道他們是誰，因此，在需要授權時，還必須以某種方式對用戶進行身份驗證。 

什麼是JWT？

根據維基百科的定義，JSON WEB Token（JWT），是一種基於JSON的、用於在網絡上聲明某種主張的令牌（token）。JWT通常由三部分組成：頭信息（header），消息體（payload）和簽名（signature）。

頭信息指定了該JWT使用的簽名算法:

header = '{"alg":"HS256","typ":"JWT"}'

HS256表示使用了HMAC-SHA256來生成簽名。

消息體包含了JWT的意圖：

payload = '{"loggedInAs":"admin","iat":1422779638}'//iat表示令牌生成的時間

未簽名的令牌由base64url編碼的頭信息和消息體拼接而成（使用”.”分隔），簽名則通過私有的key計算而成：

key = 'secretkey'  
unsignedToken = encodeBase64(header) + '.' + encodeBase64(payload)  
signature = HMAC-SHA256(key, unsignedToken)

最後在未簽名的令牌尾部拼接上base64url編碼的簽名（同樣使用”.”分隔）就是JWT了：

token = encodeBase64(header) + '.' + encodeBase64(payload) + '.' + encodeBase64(signature)

# token看起來像這樣: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJsb2dnZWRJbkFzIjoiYWRtaW4iLCJpYXQiOjE0MjI3Nzk2Mzh9.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

JWT常常被用作保護服務端的資源（resource），客戶端通常將JWT通過HTTP的Authorization header發送給服務端，服務端使用自己保存的key計算、驗證簽名以判斷該JWT是否可信：

Authorization: Bearer eyJhbGci*...<snip>...*yu5CSpyHI

準備工作

使用vs2019創建webapi項目，並且安裝nuget包

Microsoft.AspNetCore.Authentication.JwtBearer

Startup類

• ConfigureServices 添加認證服務

services.AddAuthentication(options =>
            {
                options.DefaultAuthenticateScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultChallengeScheme = JwtBearerDefaults.AuthenticationScheme;
                options.DefaultScheme = JwtBearerDefaults.AuthenticationScheme;
            }).AddJwtBearer(options =>
            {
                options.SaveToken = true;
                options.RequireHttpsMetadata = false;
                options.TokenValidationParameters = new TokenValidationParameters()
                {
                    ValidateIssuer = true,
                    ValidateAudience = true,
                    ValidAudience = "https://www.cnblogs.com/chengtian",
                    ValidIssuer = "https://www.cnblogs.com/chengtian",
                    IssuerSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("SecureKeySecureKeySecureKeySecureKeySecureKeySecureKey"))
                };
            });

• Configure 配置認證中間件

 app.UseAuthentication();//認證中間件

創建一個token

• 添加一個登錄model命名為LoginInput

public class LoginInput
    {

        public string Username { get; set; }

        public string Password { get; set; }
    }

• 添加一個認證控制器命名為AuthenticateController

[Route("api/[controller]")]
    public class AuthenticateController : Controller
    {
        [HttpPost]
        [Route("login")]
        public IActionResult Login([FromBody]LoginInput input)
        {
            //從數據庫驗證用戶名，密碼 
            //驗證通過 否則 返回Unauthorized

            //創建claim
            var authClaims = new[] {
                new Claim(JwtRegisteredClaimNames.Sub,input.Username),
                new Claim(JwtRegisteredClaimNames.Jti,Guid.NewGuid().ToString())
            };
            IdentityModelEventSource.ShowPII = true;
            //簽名秘鑰 可以放到json文件中
            var authSigningKey = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("SecureKeySecureKeySecureKeySecureKeySecureKeySecureKey"));

            var token = new JwtSecurityToken(
                   issuer: "https://www.cnblogs.com/chengtian",
                   audience: "https://www.cnblogs.com/chengtian",
                   expires: DateTime.Now.AddHours(2),
                   claims: authClaims,
                   signingCredentials: new SigningCredentials(authSigningKey, SecurityAlgorithms.HmacSha256)
                   );

            //返回token和過期時間
            return Ok(new
            {
                token = new JwtSecurityTokenHandler().WriteToken(token),
                expiration = token.ValidTo
            });
        }
    }

添加api資源

利用默認的控制器WeatherForecastController

• 添加個Authorize標籤

• 路由調整為：[Route(“api/[controller]”)] 代碼如下

 [Authorize]
    [ApiController]
    [Route("api/[controller]")]
    public class WeatherForecastController : ControllerBase

到此所有的代碼都已經准好了，下面進行運行測試

運行項目

使用postman進行模擬

• 輸入url:https://localhost:44364/api/weatherforecast

     發現返回時401未認證，下面獲取token

• 通過用戶和密碼獲取token

  如果我們的憑證正確，將會返回一個token和過期日期，然後利用該令牌進行訪問

• 利用token進行請求

  ok，最後發現請求狀態200！

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

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

　　在上一篇博文發了一天左右的時間，就收到了博客園許多讀者的評論和推薦，非常感謝，我也會及時回復讀者的評論。之後我也將繼續撰寫博文，梳理相關.NET的知識，希望.NET的圈子能越來越大，開發者能了解/深入.NET的本質，將工作做的簡單又高效，拒絕重複勞動，拒絕CRUD。

　　ok,咱們開始繼續Emit的探索。在這之前，我先放一下我往期關於Emit的文章，方便讀者閱讀。

　　《》

一、基礎知識

　　既然C#作為一門面向對象的語言，所以首當其沖的我們需要讓Emit為我們動態構建類。

　　廢話不多說，首先，我們先來回顧一下C#類的內部由什麼東西組成：

　　(1) 字段-C#類中保存數據的地方，由訪問修飾符、類型和名稱組成；

　　(2) 屬性-C#類中特有的東西，由訪問修飾符、類型、名稱和get/set訪問器組成，屬性的是用來控制類中字段數據的訪問，以實現類的封裝性；在Java當中寫作getXXX()和setXXX(val),C#當中將其變成了屬性這種語法糖；

　　(3) 方法-C#類中對邏輯進行操作的基本單元,由訪問修飾符、方法名、泛型參數、入參、出參構成；

　　(4) 構造器-C#類中一種特殊的方法，該方法是專門用來創建對象的方法，由訪問修飾符、與類名相同的方法名、入參構成。

　　接着，我們再觀察C#類本身又具備哪些東西：

　　(1) 訪問修飾符-實現對C#類的訪問控制

　　(2) 繼承-C#類可以繼承一個父類，並需要實現父類當中所有抽象的方法以及選擇實現父類的虛方法，還有就是子類需要調用父類的構造器以實現對象的創建

　　(3) 實現-C#類可以實現多個接口，並實現接口中的所有方法

　　(4) 泛型-C#類可以包含泛型參數，此外，類還可以對泛型實現約束

　　以上就是C#類所具備的一些元素，以下為樣例：

public abstract class Bar
{
    public abstract void PrintName();
}

public interface IFoo<T>
{
    public T Name { get; set; }
}
//繼承Bar基類，實現IFoo接口,泛型參數T
public class Foo<T> : Bar, IFoo<T>
　　//泛型約束
　　where T : struct
{
    //構造器
    public Foo(T name):base()
    {
        _name = name;
    }

    //字段
    private T _name;
    //屬性
    public T Name { get => _name; set => _name = value; }
    //方法
    public override void PrintName()
    {
　　　　Console.WriteLine(_name.ToString());
    }
}

　　在探索完了C#類及其定義后，我們要來了解C#的項目結構組成。我們知道C#的一個csproj項目最終會對應生成一個dll文件或者exe文件，這一個文件我們稱之為程序集Assembly；而在一個程序集中，我們內部包含和定義了許多命名空間，這些命令空間在C#當中被稱為模塊Module，而模塊正是由一個一個的C#類Type組成。

 　　所以，當我們需要定義C#類時，就必須首先定義Assembly以及Module，如此才能進行下一步工作。

二、IL概覽

 　　由於Emit實質是通過IL來生成C#代碼，故我們可以反向生成，先將寫好的目標代碼寫成cs文件，通過編譯器生成dll，再通過ildasm查看IL代碼，即可依葫蘆畫瓢的編寫出Emit代碼。所以我們來查看以下上節Foo所生成的IL代碼。

 　　從上圖我們可以很清晰的看到.NET的層級結構，位於樹頂層淺藍色圓點表示一個程序集Assembly，第二層藍色表示模塊Module，在模塊下的均為我們所定義的類，類中包含類的泛型參數、繼承類信息、實現接口信息，類的內部包含構造器、方法、字段、屬性以及它的get/set方法，由此，我們可以開始編寫Emit代碼了

三、Emit編寫

　　有了以上的對C#類的解讀和IL的解讀，我們知道了C#類本身所需要哪些元素，我們就開始根據這些元素來開始編寫Emit代碼了。這裏的代碼量會比較大，請讀者慢慢閱讀，也可以參照以上我寫的類生成il代碼進行比對。

　　在Emit當中所有創建類型的幫助類均以Builder結尾，從下錶中我們可以看的非常清楚

　　由於創建類需要從Assembly開始創建，所以我們的入口是AssemblyBuilder

　　(1) 首先，我們先引入命名空間，我們以上節Foo類為樣例進行編寫

using System.Reflection.Emit;

　　(2) 獲取基類和接口的類型

var barType = typeof(Bar);
var interfaceType = typeof(IFoo<>);

　　(3) 定義Foo類型，我們可以看到在定義類之前我們需要創建Assembly和Module

//定義類
var assemblyBuilder = AssemblyBuilder.DefineDynamicAssembly(new AssemblyName("Edwin.Blog.Emit"), AssemblyBuilderAccess.Run);
var moduleBuilder = assemblyBuilder.DefineDynamicModule("Edwin.Blog.Emit");
var typeBuilder = moduleBuilder.DefineType("Foo", TypeAttributes.Public | TypeAttributes.Class | TypeAttributes.AutoClass | TypeAttributes.AnsiClass | TypeAttributes.BeforeFieldInit);

　　(4) 定義泛型參數T,並添加約束

//定義泛型參數
var genericTypeBuilder = typeBuilder.DefineGenericParameters("T")[0];
//設置泛型約束
genericTypeBuilder.SetGenericParameterAttributes(GenericParameterAttributes.NotNullableValueTypeConstraint);

　　(5) 繼承和實現接口，注意當實現類的泛型參數需傳遞給接口時，需要將泛型接口添加泛型參數后再調用AddInterfaceImplementation方法

//繼承基類
typeBuilder.SetParent(barType);
//實現接口
typeBuilder.AddInterfaceImplementation(interfaceType.MakeGenericType(genericTypeBuilder));

　　(6) 定義字段，因為字段在構造器值需要使用，故先創建

//定義字段
var fieldBuilder = typeBuilder.DefineField("_name", genericTypeBuilder, FieldAttributes.Private);

　　(7) 定義構造器，並編寫內部邏輯

//定義構造器
var ctorBuilder = typeBuilder.DefineConstructor(MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.SpecialName | MethodAttributes.RTSpecialName, CallingConventions.Standard, new Type[] { genericTypeBuilder });
var ctorIL = ctorBuilder.GetILGenerator();
//Ldarg_0在實例方法中表示this，在靜態方法中表示第一個參數
ctorIL.Emit(OpCodes.Ldarg_0);
ctorIL.Emit(OpCodes.Ldarg_1);
//為field賦值
ctorIL.Emit(OpCodes.Stfld, fieldBuilder);
ctorIL.Emit(OpCodes.Ret);

　　(8) 定義Name屬性

//定義屬性
var propertyBuilder = typeBuilder.DefineProperty("Name", PropertyAttributes.None, genericTypeBuilder, Type.EmptyTypes);

　　(9) 編寫Name屬性的get/set訪問器

//定義get方法
var getMethodBuilder = typeBuilder.DefineMethod("get_Name", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.SpecialName | MethodAttributes.Virtual, CallingConventions.Standard, genericTypeBuilder, Type.EmptyTypes);
var getIL = getMethodBuilder.GetILGenerator();
getIL.Emit(OpCodes.Ldarg_0);
getIL.Emit(OpCodes.Ldfld, fieldBuilder);
getIL.Emit(OpCodes.Ret);
typeBuilder.DefineMethodOverride(getMethodBuilder, interfaceType.GetProperty("Name").GetGetMethod()); //實現對接口方法的重載
propertyBuilder.SetGetMethod(getMethodBuilder); //設置為屬性的get方法
//定義set方法
var setMethodBuilder = typeBuilder.DefineMethod("set_Name", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.NewSlot | MethodAttributes.SpecialName | MethodAttributes.Virtual, CallingConventions.Standard, null, new Type[] { genericTypeBuilder });
var setIL = setMethodBuilder.GetILGenerator();
setIL.Emit(OpCodes.Ldarg_0);
setIL.Emit(OpCodes.Ldarg_1);
setIL.Emit(OpCodes.Stfld, fieldBuilder);
setIL.Emit(OpCodes.Ret);
typeBuilder.DefineMethodOverride(setMethodBuilder, interfaceType.GetProperty("Name").GetSetMethod()); //實現對接口方法的重載
propertyBuilder.SetSetMethod(setMethodBuilder); //設置為屬性的set方法

 　　(10) 定義並實現PrintName方法

//定義方法
var printMethodBuilder = typeBuilder.DefineMethod("PrintName", MethodAttributes.Public | MethodAttributes.HideBySig | MethodAttributes.Virtual, CallingConventions.Standard, null, Type.EmptyTypes);
var printIL = printMethodBuilder.GetILGenerator();
printIL.Emit(OpCodes.Ldarg_0);
printIL.Emit(OpCodes.Ldflda, fieldBuilder);
printIL.Emit(OpCodes.Constrained, genericTypeBuilder);
printIL.Emit(OpCodes.Callvirt, typeof(object).GetMethod("ToString", Type.EmptyTypes));
printIL.Emit(OpCodes.Call, typeof(Console).GetMethod("WriteLine", new Type[] { typeof(string) }));
printIL.Emit(OpCodes.Ret);
//實現對基類方法的重載
typeBuilder.DefineMethodOverride(printMethodBuilder, barType.GetMethod("PrintName", Type.EmptyTypes));

　　(11) 創建類

var type = typeBuilder.CreateType(); //netstandard中請使用CreateTypeInfo().AsType()

　　(12) 調用

var obj = Activator.CreateInstance(type.MakeGenericType(typeof(DateTime)), DateTime.Now);
(obj as Bar).PrintName();
Console.WriteLine((obj as IFoo<DateTime>).Name);

四、應用

　　上面的樣例僅供學習只用，無法運用在實際項目當中，那麼，Emit構建類在實際項目中我們可以有什麼應用，提高我們的編碼效率

　　(1) 動態DTO-當我們需要將實體映射到某個DTO時，可以用動態DTO來代替你手寫的DTO，選擇你需要的字段回傳給前端，或者前端把他想要的字段傳給後端

　　(2) DynamicLinq-我的第一篇博文有個讀者提到了表達式樹，而linq使用的正是表達式樹，當表達式樹+Emit時，我們就可以用像SQL或者GraphQL那樣的查詢語句實現動態查詢

　　(3) 對象合併-我們可以編寫實現一個像js當中Object.assign()一樣的方法，實現對兩個實體的合併

　　(4) AOP動態代理-AOP的核心就是代理模式，但是與其對應的是需要手寫代理類，而Emit就可以幫你動態創建代理類，實現切面編程

　　(5) …

五、小結

　　對於Emit，確實初學者會對其感到複雜和難以學習，但是只要搞懂其中的原理，其實最終就是C#和.NET語言的本質所在，在學習Emit的同時，也是在鍛煉你的基本功是否紮實，你是否對這門語言精通，是否有各種簡化代碼的應用。

　　保持學習，勇於實踐；Write Less，Do More；作者之後還會繼續.NET高級特性系列，感謝閱讀!

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

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

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

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

　　在上一篇文章中，我們詳細的介紹了Java，那麼這些Class文件是如何被加載到內存，由虛擬機來直接使用的呢？這就是本篇博客將要介紹的——類加載過程。

1、類的生命周期

　　類從被加載到虛擬機內存開始，到卸載出內存為止，其聲明周期流程如下：

　　上圖中紅色的5個部分（加載、驗證、準備、初始化、卸載）順序是確定的，也就是說，類的加載過程必須按照這種順序按部就班的開始。這裏的“開始”不是按部就班的“進行”或者“完成”，因為這些階段通常是互相交叉混合的進行的，通常會在一個階段執行過程中調用另一個階段。

2、加載

　　“加載”階段是“類加載”生命周期的第一個階段。在加載階段，虛擬機要完成下面三件事：

　　①、通過一個類的全限定名來獲取定義此類的二進制字節流。

　　②、將這個字節流所代表的靜態存儲結構轉化為方法區的運行時數據結構。

　　③、在Java堆中生成一個代表這個類的java.lang.Class對象，作為方法區這些數據的訪問入口。

　　PS：類的全限定名可以理解為這個類存放的絕對路徑。方法區是JDK1.7以前定義的運行時數據區，而在JDK1.8以後改為元數據區（Metaspace），主要用於存放被Java虛擬機加載的類信息、常量、靜態變量、即時編譯器編譯后的代碼等數據。詳情可以參考這邊該系列的第二篇文章——。

　　另外，我們看第一點——通過類的權限定名來獲取定義此類的二進制流，這裏並沒有明確指明要從哪裡獲取以及怎樣獲取，也就是說並沒有明確規定一定要我們從一個 Class 文件中獲取。基於此，在Java的發展過程中，充滿創造力的開發人員在這個舞台上玩出了各種花樣：

　　1、從 ZIP 包中讀取。這稱為後面的 JAR、EAR、WAR 格式的基礎。

　　2、從網絡中獲取。比較典型的應用就是 Applet。

　　3、運行時計算生成。這就是動態代理技術。

　　4、由其它文件生成。比如 JSP 應用。

　　5、從數據庫中讀取。

　　加載階段完成后，虛擬機外部的二進制字節流就按照虛擬機所需的格式存儲在方法區中，然後在Java堆中實例化一個 java.lang.Class 類的對象，這個對象將作為程序訪問方法區中這些類型數據的外部接口。

　　注意，加載階段與連接階段的部分內容（如一部分字節碼文件的格式校驗）是交叉進行的，加載階段尚未完成，連接階段可能已經開始了。

3、驗證

　　驗證是連接階段的第一步，作用是為了確保 Class 文件的字節流中包含的信息符合當前虛擬機的要求，並且不會危害虛擬機自身的安全。

　　我們說Java語言本身是相對安全，因為編譯器的存在，純粹的Java代碼要訪問數組邊界外的數據、跳轉到不存在的代碼行之類的，是要被編譯器拒絕的。但是前面我們也說過，Class 文件不一定非要從Java源碼編譯過來，可以使用任何途徑，包括你很牛逼，直接用十六進制編輯器來編寫 Class 文件。

　　所以，如果虛擬機不檢查輸入的字節流，將會載入有害的字節流而導致系統崩潰。但是虛擬機規範對於檢查哪些方面，何時檢查，怎麼檢查都沒有明確的規定，不同的虛擬機實現方式可能都會有所不同，但是大致都會完成下面四個方面的檢查。

①、文件格式驗證

　　校驗字節流是否符合Class文件格式的規範，並且能夠被當前版本的虛擬機處理。

　　一、是否以魔數 0xCAFEBABE 開頭。

　　二、主、次版本號是否是當前虛擬機處理範圍之內。

　　三、常量池的常量中是否有不被支持的常量類型（檢查常量tag標誌）

　　四、指向常量的各種索引值中是否有指向不存在的常量或不符合類型的常量。

　　五、CONSTANT_Utf8_info 型的常量中是否有不符合 UTF8 編碼的數據。

　　六、Class 文件中各個部分及文件本身是否有被刪除的或附加的其他信息。

　　以上是一部分校驗內容，當然遠不止這些。經過這些校驗后，字節流才會進入內存的方法區中存儲，接下來後面的三個階段校驗都是基於方法區的存儲結構進行的。

②、元數據驗證

　　第二個階段主要是對字節碼描述的信息進行語義分析，以保證其描述的信息符合Java語言規範要求。

　　一、這個類是否有父類（除了java.lang.Object 類之外，所有的類都應當有父類）。

　　二、這個類的父類是否繼承了不允許被繼承的類（被final修飾的類）。

　　三、如果這個類不是抽象類，是否實現了其父類或接口之中要求實現的所有普通方法。

　　四、類中的字段、方法是否與父類產生了矛盾（例如覆蓋了父類的final字段、或者出現不符合規則的重載）

③、字節碼驗證

　　第三個階段字節碼驗證是整個驗證階段中最複雜的，主要是進行數據流和控制流分析。該階段將對類的方法進行分析，保證被校驗的方法在運行時不會做出危害虛擬機安全的行為。

　　一、保證任意時刻操作數棧中的數據類型與指令代碼序列都能配合工作。例如不會出現在操作數棧中放置了一個 int 類型的數據，使用時卻按照 long 類型來加載到本地變量表中。

　　二、保證跳轉指令不會跳轉到方法體以外的字節碼指令中。

　　三、保證方法體中的類型轉換是有效的。比如把一個子類對象賦值給父類數據類型，這是安全的。但是把父類對象賦值給子類數據類型，甚至賦值給完全不相干的類型，這就是不合法的。

④、符號引用驗證

　　符號引用驗證主要是對類自身以外（常量池中的各種符號引用）的信息進行匹配性的校驗，通常需要校驗如下內容：

　　一、符號引用中通過字符串描述的全限定名是否能夠找到相應的類。

　　二、在指定類中是否存在符合方法的字段描述符及簡單名稱所描述的方法和字段。

　　三、符號引用中的類、字段和方法的訪問性（private、protected、public、default）是否可以被當前類訪問。

4、準備

　　準備階段是正式為類變量分配內存並設置類變量初始值的階段，這些內存是在方法區中進行分配。

　　注意：

　　一、上面說的是類變量，也就是被 static 修飾的變量，不包括實例變量。實例變量會在對象實例化時隨着對象一起分配在堆中。

　　二、初始值，指的是一些數據類型的默認值。基本的數據類型初始值如下（引用類型的初始值為null）：

 　　比如，定義 public static int value = 123 。那麼在準備階段過後，value 的值是 0 而不是 123,把 value 賦值為123 是在程序被編譯后，存放在類的構造器方法之中，是在初始化階段才會被執行。但是有一種特殊情況，通過final 修飾的屬性，比如 定義 public final static int value = 123，那麼在準備階段過後，value 就被賦值為123了。

5、解析

　　解析階段是虛擬機將常量池中的符號引用替換為直接引用的過程。

　　符號引用（Symbolic References）：符號引用以一組符號來描述所引用的目標，符號可以是任何形式的字面量，只要使用時能無歧義的定位到目標即可。符號引用與虛擬機實現的內存布局無關，引用的目標不一定已經加載到內存中。

　　直接引用（Direct References）：直接引用可以是直接指向目標的指針、相對偏移量或是一個能間接定位到目標的句柄。直接引用是與虛擬機實現內存布局相關的，同一個符號引用在不同虛擬機實例上翻譯出來的直接引用一般不會相同。如果有了直接引用，那麼引用的目標必定已經在內存中存在。

　　解析動作主要針對類或接口、字段、類方法、接口方法四類符號引用，分別對應於常量池的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANTS_InterfaceMethodref_info四種類型常量。

6、初始化

 　　初始化階段是類加載階段的最後一步，前面過程中，除第一個加載階段可以通過用戶自定義類加載器參与之外，其餘過程都是完全由虛擬機主導和控制。而到了初始化階段，則開始真正執行類中定義的Java程序代碼（或者說是字節碼）。

　　在前面介紹的準備階段中，類變量已經被賦值過初始值了，而初始化階段，則根據程序員的編碼去初始化變量和資源。

　　換句話來說，初始化階段是執行類構造器<clinit>() 方法的過程。

　　①、<clinit>() 方法 是由編譯器自動收集類中的所有類變量的賦值動作和靜態語句塊（static{}）中的語句合併產生的，編譯器收集的順序是由語句在源文件中出現的順序所決定的，靜態語句塊中只能訪問到定義在靜態語句塊之前的變量，定義在它之後的變量，在前面的靜態語句塊中可以賦值，但是不能訪問。

　　比如如下代碼會報錯：

 　　但是你把第 14 行代碼放到 static 靜態代碼塊的上面就不會報錯了。或者不改變代碼順序，將第 11 行代碼移除，也不會報錯。

　　②、<clinit>() 方法與類的構造函數（或者說是實例構造器<init>()方法）不同，它不需要显示的調用父類構造器，虛擬機會保證在子類的<init>()方法執行之前，父類的<init>()方法已經執行完畢。因此虛擬機中第一個被執行的<init>()方法的類肯定是 java.lang.Object。

　　③、由於父類的<clinit>() 方法先執行，所以父類中定義的靜態語句塊要優先於子類的變量賦值操作。

　　④、<clinit>() 方法對於接口來說並不是必須的，如果一個類中沒有靜態語句塊，也沒有對變量的賦值操作，那麼編譯器可以不為這個類生成<clinit>() 方法。

　　⑤、接口中不能使用靜態語句塊，但仍然有變量初始化的賦值操作，因此接口與類一樣都會生成<clinit>() 方法。但接口與類不同的是，執行接口中的<clinit>() 方法不需要先執行父接口的<clinit>() 方法。只有當父接口中定義的變量被使用時，父接口才會被初始化。

　　⑥、接口的實現類在初始化時也一樣不會執行接口的<clinit>() 方法。

　　⑦、虛擬機會保證一個類的<clinit>() 方法在多線程環境中被正確的加鎖和同步。如果多個線程同時去初始化一個類，那麼只會有一個線程去執行這個類的<clinit>() 方法，其他的線程都需要阻塞等待，直到活動線程執行<clinit>() 方法完畢。如果在一個類的<clinit>() 方法中有很耗時的操作，那麼可能造成多個進程的阻塞。

　　比如對於如下代碼：

package com.yb.carton.controller;

/**
 * Create by YSOcean
 */
public class ClassLoadInitTest {


    static class Hello{
        static {
            if(true){
                System.out.println(Thread.currentThread().getName() + "init");
                while(true){}
            }
        }
    }

    public static void main(String[] args) {
        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"start");
            Hello h1 = new Hello();
            System.out.println(Thread.currentThread().getName()+"run over");
        }).start();


        new Thread(()->{
            System.out.println(Thread.currentThread().getName()+"start");
            Hello h2 = new Hello();
            System.out.println(Thread.currentThread().getName()+"run over");
        }).start();
    }

}

View Code

　　運行結果如下：

 　　線程1搶到了執行<clinit>() 方法，但是該方法是一個死循環，線程2將一直阻塞等待。

　　知道了類的初始化過程，那麼類的初始化何時被觸發呢？JVM大概規定了如下幾種情況：

　　①、當虛擬機啟動時，初始化用戶指定的類。

　　②、當遇到用以新建目標類實例的 new 指令時，初始化 new 指定的目標類。

　　③、當遇到調用靜態方法的指令時，初始化該靜態方法所在的類。

　　④、當遇到訪問靜態字段的指令時，初始化該靜態字段所在的類。

　　⑤、子類的初始化會觸發父類的初始化。

　　⑥、如果一個接口定義了 default 方法，那麼直接實現或間接實現該接口的類的初始化，會觸發該接口的初始化。

　　⑦、使用反射 API 對某個類進行反射調用時，會初始化這個類。

　　⑧、當初次調用 MethodHandle 實例時，初始化該 MethodHandle 指向的方法所在的類。

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

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

文章來源：

一、前言

日常開發過程有時需要在應用啟動之後加載某些資源，或者在應用關閉之前釋放資源。Spring 框架提供相關功能，圍繞 Spring Bean 生命周期，可以在 Bean 創建過程初始化資源，以及銷毀 Bean 過程釋放資源。Spring 提供多種不同的方式初始化/銷毀 Bean，如果同時使用這幾種方式，Spring 如何處理這幾者之間的順序？

有沒有覺得標題很熟悉，沒錯標題模仿二哥 「@沉默王二」 文章。

二、姿勢剖析

首先我們先來回顧一下 Spring 初始化/銷毀 Bean 幾種方式，分別為：

• init-method/destroy-method
• InitializingBean/DisposableBean
• @PostConstruct/@PreDestroy
• ContextStartedEvent/ContextClosedEvent

PS: 其實還有一種方式，就是繼承 Spring Lifecycle 接口。不過這種方式比較繁瑣，這裏就不再分析。

2.1、init-method/destroy-method

這種方式在配置文件文件指定初始化/銷毀方法。XML 配置如下

<bean id="demoService" class="com.dubbo.example.provider.DemoServiceImpl"  destroy-method="close"  init-method="initMethod"/>

或者也可以使用註解方式配置：

@Configurable
public class AppConfig {

    @Bean(initMethod = "init", destroyMethod = "destroy")
    public HelloService hello() {
        return new HelloService();
    }
}

還記得剛開始接觸學習 Spring 框架，使用就是這種方式。

2.2、InitializingBean/DisposableBean

這種方式需要繼承 Spring 接口 InitializingBean/DisposableBean，其中 InitializingBean 用於初始化動作，而 DisposableBean 用於銷毀之前清理動作。使用方式如下：

@Service
public class HelloService implements InitializingBean, DisposableBean {
    
    @Override
    public void destroy() throws Exception {
        System.out.println("hello destroy...");
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("hello init....");
    }
}

2.3、@PostConstruct/@PreDestroy

這種方式相對於上面兩種方式來說，使用方式最簡單，只需要在相應的方法上使用註解即可。使用方式如下：

@Service
public class HelloService {


    @PostConstruct
    public void init() {
        System.out.println("hello @PostConstruct");
    }

    @PreDestroy
    public void PreDestroy() {
        System.out.println("hello @PreDestroy");
    }
}

這裏踩過一個坑，如果使用 JDK9 之後版本 ，@PostConstruct/@PreDestroy 需要使用 maven 單獨引入 javax.annotation-api，否者註解不會生效。

2.4、ContextStartedEvent/ContextClosedEvent

這種方式使用 Spring 事件機制，日常業務開發比較少見，常用與框架集成中。Spring 啟動之後將會發送 ContextStartedEvent 事件，而關閉之前將會發送 ContextClosedEvent 事件。我們需要繼承 Spring ApplicationListener 才能監聽以上兩種事件。

@Service
public class HelloListener implements ApplicationListener {

    @Override
    public void onApplicationEvent(ApplicationEvent event) {
        if(event instanceof ContextClosedEvent){
            System.out.println("hello ContextClosedEvent");
        }else if(event instanceof ContextStartedEvent){
            System.out.println("hello ContextStartedEvent");
        }

    }
}

也可以使用 @EventListener註解，使用方式如下：

public class HelloListenerV2 {
    
    @EventListener(value = {ContextClosedEvent.class, ContextStartedEvent.class})
    public void receiveEvents(ApplicationEvent event) {
        if (event instanceof ContextClosedEvent) {
            System.out.println("hello ContextClosedEvent");
        } else if (event instanceof ContextStartedEvent) {
            System.out.println("hello ContextStartedEvent");
        }
    }
}

PS:只有調用 ApplicationContext#start 才會發送 ContextStartedEvent。若不想這麼麻煩，可以監聽 ContextRefreshedEvent 事件代替。一旦 Spring 容器初始化完成，就會發送 ContextRefreshedEvent。

三、綜合使用

回顧完上面幾種方式，這裏我們綜合使用上面的四種方式，來看下 Spring 內部的處理順序。在看結果之前，各位讀者大人可以猜測下這幾種方式的執行順序。

public class HelloService implements InitializingBean, DisposableBean {


    @PostConstruct
    public void init() {
        System.out.println("hello @PostConstruct");
    }

    @PreDestroy
    public void PreDestroy() {
        System.out.println("hello @PreDestroy");
    }

    @Override
    public void destroy() throws Exception {
        System.out.println("bye DisposableBean...");
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("hello InitializingBean....");
    }

    public void xmlinit(){
        System.out.println("hello xml-init...");
    }

    public void xmlDestory(){
        System.out.println("bye xmlDestory...");
    }

    @EventListener(value = {ContextClosedEvent.class, ContextStartedEvent.class})
    public void receiveEvents(ApplicationEvent event) {
        if (event instanceof ContextClosedEvent) {
            System.out.println("bye ContextClosedEvent");
        } else if (event instanceof ContextStartedEvent) {
            System.out.println("hello ContextStartedEvent");
        }
    }

}

xml 配置方式如下：

    <context:annotation-config />
    <context:component-scan base-package="com.dubbo.example.demo"/>
    
    <bean class="com.dubbo.example.demo.HelloService" init-method="xmlinit" destroy-method="xmlDestory"/>

應用啟動方法如下：

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("spring/dubbo-provider.xml");
context.start();
context.close();

程序輸出結果如下所示：

最後採用圖示說明總結以上結果：

四、源碼解析

不知道各位讀者有沒有猜對這幾種方式的執行順序，下面我們就從源碼角度解析 Spring 內部處理的順序。

4.1、初始化過程

使用 ClassPathXmlApplicationContext 啟動 Spring 容器，將會調用 refresh 方法初始化容器。初始化過程將會創建 Bean 。最後當一切準備完畢，將會發送 ContextRefreshedEvent。當容器初始化完畢，調用 context.start() 就發送 ContextStartedEvent 事件。

refresh 方法源碼如下：

public void refresh() throws BeansException, IllegalStateException {
    synchronized (this.startupShutdownMonitor) {
            //... 忽略無關代碼

            // 初始化所有非延遲初始化的 Bean
            finishBeanFactoryInitialization(beanFactory);

            // 發送 ContextRefreshedEvent
            finishRefresh();

            //... 忽略無關代碼
    }
}

一路跟蹤 finishBeanFactoryInitialization 源碼，直到 AbstractAutowireCapableBeanFactory#initializeBean，源碼如下：

protected Object initializeBean(final String beanName, final Object bean, RootBeanDefinition mbd) {
    Object wrappedBean = bean;
    if (mbd == null || !mbd.isSynthetic()) {
        // 調用 BeanPostProcessor#postProcessBeforeInitialization 方法
        wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
    }

    try {
        // 初始化 Bean
        invokeInitMethods(beanName, wrappedBean, mbd);
    }
    catch (Throwable ex) {
        throw new BeanCreationException(
                (mbd != null ? mbd.getResourceDescription() : null),
                beanName, "Invocation of init method failed", ex);
    }
}

BeanPostProcessor 將會起着攔截器的作用，一旦 Bean 符合條件，將會執行一些處理。這裏帶有 @PostConstruct 註解的 Bean 都將會被 CommonAnnotationBeanPostProcessor 類攔截，內部將會觸發 @PostConstruct 標註的方法。

接着執行 invokeInitMethods ，方法如下:

protected void invokeInitMethods(String beanName, final Object bean, RootBeanDefinition mbd)
        throws Throwable {

    boolean isInitializingBean = (bean instanceof InitializingBean);
    if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
        // 省略無關代碼
        // 如果是 Bean 繼承 InitializingBean，將會執行  afterPropertiesSet 方法
        ((InitializingBean) bean).afterPropertiesSet();
    }

    if (mbd != null) {
        String initMethodName = mbd.getInitMethodName();
        if (initMethodName != null && !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
                !mbd.isExternallyManagedInitMethod(initMethodName)) {
            // 執行 XML 定義 init-method
            invokeCustomInitMethod(beanName, bean, mbd);
        }
    }
}

如果 Bean 繼承 InitializingBean 接口，將會執行 afterPropertiesSet 方法，另外如果在 XML 中指定了 init-method ，也將會觸發。

上面源碼其實都是圍繞着 Bean 創建的過程，當所有 Bean 創建完成之後，調用 context#start 將會發送 ContextStartedEvent 。這裏源碼比較簡單，如下：

public void start() {
    getLifecycleProcessor().start();
    publishEvent(new ContextStartedEvent(this));
}

4.2、銷毀過程

調用 ClassPathXmlApplicationContext#close 方法將會關閉容器，具體邏輯將會在 doClose 方法執行。

doClose 這個方法首先發送 ContextClosedEvent，然再后開始銷毀 Bean。

靈魂拷問:如果我們顛倒上面兩者順序，結果會一樣嗎？

doClose 源碼如下：

protected void doClose() {
    if (this.active.get() && this.closed.compareAndSet(false, true)) {
        // 省略無關代碼

        try {
            // Publish shutdown event.
            publishEvent(new ContextClosedEvent(this));
        }
        catch (Throwable ex) {
            logger.warn("Exception thrown from ApplicationListener handling ContextClosedEvent", ex);
        }


        // 銷毀 Bean
        destroyBeans();

        // 省略無關代碼
    }
}

destroyBeans 最終將會執行 DisposableBeanAdapter#destroy，@PreDestroy、DisposableBean、destroy-method 三者定義的方法都將會在內部被執行。

首先執行 DestructionAwareBeanPostProcessor#postProcessBeforeDestruction，這裏方法類似與上面 BeanPostProcessor。

@PreDestroy 註解將會被 CommonAnnotationBeanPostProcessor 攔截，這裏類同時也繼承了 DestructionAwareBeanPostProcessor。

最後如果 Bean 為 DisposableBean 的子類，將會執行 destroy 方法，如果在 xml 定義了 destroy-method 方法，該方法也會被執行。

public void destroy() {
    if (!CollectionUtils.isEmpty(this.beanPostProcessors)) {
        for (DestructionAwareBeanPostProcessor processor : this.beanPostProcessors) {
            processor.postProcessBeforeDestruction(this.bean, this.beanName);
        }
    }

    if (this.invokeDisposableBean) {
        // 省略無關代碼
        // 如果 Bean 繼承 DisposableBean，執行 destroy 方法
        ((DisposableBean) bean).destroy();
        
    }

    if (this.destroyMethod != null) {
        // 執行 xml 指定的  destroy-method 方法
        invokeCustomDestroyMethod(this.destroyMethod);
    }
    else if (this.destroyMethodName != null) {
        Method methodToCall = determineDestroyMethod();
        if (methodToCall != null) {
            invokeCustomDestroyMethod(methodToCall);
        }
    }
}

五、總結

init-method/destroy-method 這種方式需要使用 XML 配置文件或單獨註解配置類，相對來說比較繁瑣。而InitializingBean/DisposableBean 這種方式需要單獨繼承 Spring 的接口實現相關方法。@PostConstruct/@PreDestroy 這種註解方式使用方式簡單，代碼清晰，比較推薦使用這種方式。

另外 ContextStartedEvent/ContextClosedEvent 這種方式比較適合在一些集成框架使用，比如 Dubbo 2.6.X 優雅停機就是用改機制。

六、Spring 歷史文章推薦

歡迎關注我的公眾號：程序通事，獲得日常乾貨推送。如果您對我的專題內容感興趣，也可以關注我的博客：

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

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選

本文源碼： ||

一、生活場景

1、場景描述

電競是遊戲比賽達到“競技”層面的體育項目。利用电子設備作為運動器械進行的、人與人之間的智力對抗運動。通過電競，可以提高人的反應能力、協調能力、團隊精神等。但是不同人群的對電競的持有的觀念不一樣，有的人認為電競就是沉迷網絡，持反對態度，而有的人就比較贊同。下面基於訪問者模式來描述該場景。

2、場景圖解

3、代碼實現

public class C01_InScene {
    public static void main(String[] args) {
        DataSet dataSet = new DataSet() ;
        dataSet.addCrowd(new Youth());
        dataSet.addCrowd(new MiddleAge());
        CrowdView crowdView = new Against() ;
        dataSet.display(crowdView);
        crowdView = new Approve() ;
        dataSet.display(crowdView);
    }
}
/**
 * 雙分派,不同人群管理
 */
abstract class Crowd {
    abstract void accept(CrowdView action);
}
class Youth extends Crowd {
    @Override
    public void accept(CrowdView view) {
        view.getYouthView(this);
    }
}
class MiddleAge extends Crowd {
    @Override
    public void accept(CrowdView view) {
        view.getMiddleAgeView (this);
    }
}
/**
 * 不同人群觀念的管理
 */
abstract class CrowdView {
    // 青年人觀念
    abstract void getYouthView (Youth youth);
    // 中年人觀念
    abstract void getMiddleAgeView (MiddleAge middleAge);
}
class Approve extends CrowdView {
    @Override
    public void getYouthView(Youth youth) {
        System.out.println("青年人贊同電競");
    }
    @Override
    public void getMiddleAgeView(MiddleAge middleAge) {
        System.out.println("中年人贊同電競");
    }
}
class Against extends CrowdView {
    @Override
    public void getYouthView(Youth youth) {
        System.out.println("青年人反對電競");
    }
    @Override
    public void getMiddleAgeView(MiddleAge middleAge) {
        System.out.println("中年人反對電競");
    }
}
/**
 * 提供一個數據集合
 */
class DataSet {
    private List<Crowd> crowdList = new ArrayList<>();
    public void addCrowd (Crowd crowd) {
        crowdList.add(crowd);
    }
    public void display(CrowdView crowdView) {
        for(Crowd crowd : crowdList) {
            crowd.accept(crowdView);
        }
    }
}

二、訪問者模式

1、基礎概念

訪問者模式是對象的行為模式，把作用於數據結構的各元素的操作封裝，操作之間沒有關聯。可以在不改變數據結構的前提下定義作用於這些元素的不同的操作。主要將數據結構與數據操作分離，解決數據結構和操作耦合問題核心原理：被訪問的類裏面加對外提供接待訪問者的接口。

2、模式圖解

3、核心角色

• 抽象訪問者角色

聲明多個方法操作，具體訪問者角色需要實現的接口。

• 具體訪問者角色

實現抽象訪問者所聲明的接口，就是各個訪問操作。

• 抽象節點角色

聲明接受操作，接受訪問者對象作為參數。

• 具體節點角色

實現抽象節點所規定的具體操作。

• 結構對象角色

能枚舉結構中的所有元素，可以提供一個高層的接口，用來允許訪問者對象訪問每一個元素。

4、源碼實現

public class C02_Visitor {
    public static void main(String[] args) {
        ObjectStructure obs = new ObjectStructure();
        obs.add(new NodeA());
        obs.add(new NodeB());
        Visitor visitor = new VisitorA();
        obs.doAccept(visitor);
    }
}
/**
 * 抽象訪問者角色
 */
interface Visitor {
    /**
     * NodeA的訪問操作
     */
    void visit(NodeA node);
    /**
     * NodeB的訪問操作
     */
    void visit(NodeB node);
}
/**
 * 具體訪問者角色
 */
class VisitorA implements Visitor {
    @Override
    public void visit(NodeA node) {
        node.operationA() ;
    }
    @Override
    public void visit(NodeB node) {
        node.operationB() ;
    }
}
class VisitorB implements Visitor {
    @Override
    public void visit(NodeA node) {
        node.operationA() ;
    }
    @Override
    public void visit(NodeB node) {
        node.operationB() ;
    }
}
/**
 * 抽象節點角色
 */
abstract class Node {
    /**
     * 接收訪問者
     */
    abstract void accept(Visitor visitor);
}
/**
 * 具體節點角色
 */
class NodeA extends Node{
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
    public void operationA(){
        System.out.println("NodeA.operationA");
    }
}
class NodeB extends Node{
    @Override
    public void accept(Visitor visitor) {
        visitor.visit(this);
    }
    public void operationB(){
        System.out.println("NodeB.operationB");
    }
}
/**
 * 結構對象角色類
 */
class ObjectStructure {
    private List<Node> nodes = new ArrayList<>();
    public void detach(Node node) {
        nodes.remove(node);
    }
    public void add(Node node){
        nodes.add(node);
    }
    public void doAccept(Visitor visitor){
        for(Node node : nodes) {
            node.accept(visitor);
        }
    }
}

三、Spring框架應用

1、Bean結構的訪問

BeanDefinitionVisitor類，遍歷bean的各個屬性；接口 BeanDefinition，定義Bean的各樣信息，比如屬性值、構造方法、參數等等。這裏封裝操作bean結構的相關方法，但卻沒有改變bean的結構。

2、核心代碼塊

public class BeanDefinitionVisitor {
    public void visitBeanDefinition(BeanDefinition beanDefinition) {
        this.visitParentName(beanDefinition);
        this.visitBeanClassName(beanDefinition);
        this.visitFactoryBeanName(beanDefinition);
        this.visitFactoryMethodName(beanDefinition);
        this.visitScope(beanDefinition);
        if (beanDefinition.hasPropertyValues()) {
            this.visitPropertyValues(beanDefinition.getPropertyValues());
        }
        if (beanDefinition.hasConstructorArgumentValues()) {
            ConstructorArgumentValues cas = beanDefinition.getConstructorArgumentValues();
            this.visitIndexedArgumentValues(cas.getIndexedArgumentValues());
            this.visitGenericArgumentValues(cas.getGenericArgumentValues());
        }
    }
}

四、模式總結

1、優點描述

(1) 訪問者模式符合單一職責原則、使程序具有良好的擴展性、靈活性；

(2) 訪問者模式適用與攔截器與過濾器等常見功能，數據結構相對穩定的場景；

2、缺點描述

(1) 訪問者關注其他類的內部細節，依賴性強，違反迪米特法則,這樣導致具體元素更新麻煩；

(2) 訪問者依賴具體元素，不是抽象元素，面向細節編程，違背依賴倒轉原則；

五、源代碼地址

GitHub·地址
https://github.com/cicadasmile/model-arithmetic-parent
GitEE·地址
https://gitee.com/cicadasmile/model-arithmetic-parent

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

※USB CONNECTOR掌控什麼技術要點? 帶您認識其相關發展及效能

※評比前十大台北網頁設計、台北網站設計公司知名案例作品心得分享

※智慧手機時代的來臨，RWD網頁設計已成為網頁設計推薦首選