背景

java 8已經發行好幾年了，前段時間java 12也已經問世，但平時的工作中，很多項目的環境還停留在java1.7中。而且java8的很多新特性都是革命性的，比如各種集合的優化、lambda表達式等，所以我們還是要去了解java8的魅力。

今天我們來學習java8的Stream，並不需要理論基礎，直接可以上手去用。

我接觸stream的原因，是我要搞一個用戶收入消費的數據分析。起初的統計篩選分組都是打算用sql語言直接從mysql里得到結果來展現的。但在操作中我們發現這樣頻繁地訪問數據庫，性能會受到很大的影響，分析速度會很慢。所以我們希望能通過訪問一次數據庫就拿到所有數據，然後放到內存中去進行數據分析統計過濾。

接着，我看了stream的API，發現這就是我想要的。

一、Stream理解

在java中我們稱Stream為『流』，我們經常會用流去對集合進行一些流水線的操作。stream就像工廠一樣，只需要把集合、命令還有一些參數灌輸到流水線中去，就可以加工成得出想要的結果。這樣的流水線能大大簡潔代碼，減少操作。

二、Stream流程

原集合 —> 流  —> 各種操作(過濾、分組、統計) —> 終端操作

 

Stream流的操作流程一般都是這樣的，先將集合轉為流，然後經過各種操作，比如過濾、篩選、分組、計算。最後的終端操作，就是轉化成我們想要的數據，這個數據的形式一般還是集合，有時也會按照需求輸出count計數。下文會一一舉例。

三、API功能舉例

首先，定義一個用戶對象，包含姓名、年齡、性別和籍貫四個成員變量：

import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.extern.log4j.Log4j;

@Data
@NoArgsConstructor
@AllArgsConstructor
@Log4j
@Builder
public class User {
    //姓名
    private String name;
    //年齡
    private Integer age;
    //性別
    private Integer sex;
    //所在省市
    private String address;
}

 

這裏用lombok簡化了實體類的代碼。

然後創建需要的集合數據，也就是源數據：

//1.構建我們的list
List<User> list= Arrays.asList(
        new User("鋼鐵俠",40,0,"華盛頓"),
        new User("蜘蛛俠",20,0,"華盛頓"),
        new User("趙麗穎",30,1,"湖北武漢市"),
        new User("詹姆斯",35,0,"洛杉磯"),
        new User("李世民",60,0,"山西省太原市"),
        new User("蔡徐坤",20,1,"陝西西安市"),
        new User("葫蘆娃的爺爺",70,0,"山西省太原市")
);

 

3.1 過濾

1）創建流 stream() / parallelStream()

• stream() : 串行流
• parallelStream（）: 并行流

2）filter 過濾(T-> boolean)

比如要過濾年齡在40歲以上的用戶，就可以這樣寫：

List<User> filterList = list.stream().filter(user -> user.getAge() >= 40)
        .collect(toList());

 

filter裏面，->箭頭後面跟着的是一個boolean值，可以寫任何的過濾條件，就相當於sql中where後面的東西，換句話說，能用sql實現的功能這裏都可以實現

打印結果：

3）distinct 去重

和sql中的distinct關鍵字很相似。為了看到效果，此處在原集合中加入一個重複的人，就選擇鋼鐵俠吧，復聯4鋼鐵俠不幸遇害，大家還是比較傷心的。

List<User> list= Arrays.asList(
        new User("鋼鐵俠",40,0,"華盛頓"),
        new User("鋼鐵俠",40,0,"華盛頓"),
        new User("蜘蛛俠",20,0,"華盛頓"),
        new User("趙麗穎",30,1,"湖北武漢市"),
        new User("詹姆斯",35,0,"洛杉磯"),
        new User("李世民",60,0,"山西省太原市"),
        new User("蔡徐坤”,18,1,"陝西西安市"),
        new User("葫蘆娃的爺爺",70,0,"山西省太原市")
);

 

//distinct 去重
List<User> distinctList = filterList.stream().distinct()
        .collect(toList());

 

打印結果：

4）sorted排序

如果流中的元素的類實現了 Comparable 接口，即有自己的排序規則，那麼可以直接調用 sorted() 方法對元素進行排序，如： 

Comparator.comparingInt

 

反之, 需要調用 sorted((T, T) -> int) 實現 Comparator 接口。

//sorted()
List<User> sortedList = distinctList.stream().sorted(Comparator.comparingInt(User::getAge))
        .collect(toList());

 

打印結果：

結果按照年齡從小到大進行排序。

5）limit（） 返回前n個元素

如果想知道這裏面年齡最小的是誰，可作如下操作：

//limit 返回前n個元素
List<User> limitList = sortedList.stream().limit(1)
        .collect(toList());

 

6）skip()

與limit恰恰相反，skip的意思是跳過，也就是去除前n個元素。

打印結果：

果然，前兩個人都被去除了，只剩下最老的葫蘆娃爺爺。

3.2 映射

1）map(T->R)

map是將T類型的數據轉為R類型的數據，比如我們想要設置一個新的list，存儲用戶所有的城市信息。

//map(T->R)
List<String> cityList = list.stream().map(User::getAddress).distinct().collect(toList());

 

打印結果：

2）flatMap(T -> Stream)

將流中的每一個元素 T 映射為一個流，再把每一個流連接成為一個流。

//flatMap(T -> Stream<R>)
List<String> flatList = new ArrayList<>();
flatList.add("唱,跳");
flatList.add("rape,籃球,music");
flatList = flatList.stream().map(s -> s.split(",")).flatMap(Arrays::stream).collect(toList());

 

打印結果：

這裏原集合中的數據由逗號分割，使用split進行拆分后，得到的是Stream<string[]>，字符串數組組成的流，要使用flatMap的

Arrays::stream

將Stream<string[]>轉為Stream,然後把流相連接，組成了完整的唱、跳、rap、籃球和music。

3.3 查找

1）allMatch（T->boolean）

檢測是否全部滿足參數行為，假如這些用戶是網吧上網的用戶名單，那就需要檢查是不是每個人都年滿18周歲了。

boolean isAdult = list.stream().allMatch(user -> user.getAge() >= 18);

 

打印結果：

true

 

2）anyMatch（T->boolean）

檢測是否有任意元素滿足給定的條件，比如，想知道同學名單里是否有女生。

//anyMatch(T -> boolean） 是否有任意一個元素滿足給定的條件
boolean isGirl = list.stream().anyMatch(user -> user.getSex() == 1);

 

打印結果：

true

 

說明集合中有女生存在。

3）noneMatch(T -> boolean)

流中是否有元素匹配給定的 T -> boolean 條件。

比如檢測有沒有來自巴黎的用戶。

boolean isLSJ = list.stream().noneMatch(user -> user.getAddress().contains("巴黎"));

 

打印結果：

true

 

打印true說明沒有巴黎的用戶。

4）findFirst( ):找到第一個元素

Optional<User> fristUser  = list.stream().findFirst();

 

打印結果：

User(name=鋼鐵俠, age=40, sex=0, address=華盛頓)

 

5）findAny():找到任意一個元素

Optional<User> anyUser  = list.stream().findAny();

 

打印結果：

User(name=鋼鐵俠, age=40, sex=0, address=華盛頓)

 

這裏我們發現findAny返回的也總是第一個元素，那麼為什麼還要進行區分呢？因為在并行流 parallelStream() 中找到的確實是任意一個元素。

Optional<User> anyParallelUser  = list.parallelStream().findAny();

 

打印結果 :

Optional[User(name=李世民, age=60, sex=0, address=山西省太原市)]

 

3.4 歸納計算

1）求用戶的總人數

long count = list.stream().collect(Collectors.counting());

 

我們可以簡寫為：

long count = list.stream().count();

 

運行結果：

 8

 

2）得到某一屬性的最大最小值

// 求最大年齡
Optional<User> max = list.stream().collect(Collectors.maxBy(
Comparator.comparing(User::getAge)));

// 求最小年齡
Optional<User> min = list.stream().collect(Collectors.minBy(
Comparator.comparing(User::getAge)));

 

運行結果：

3）求年齡總和是多少

// 求年齡總和
int totalAge = list.stream().collect(Collectors.summingInt(User::getAge));

 

運行結果：

 313

 

我們經常會用BigDecimal來記錄金錢，假設想得到BigDecimal的總和：

// 獲得列表對象金額， 使用reduce聚合函數,實現累加器
BigDecimal sum = myList.stream() .map(User::getMoney)
.reduce(BigDecimal.ZERO,BigDecimal::add);

 

4）求年齡平均值

//求年齡平均值
double avgAge = list.stream().collect(
Collectors.averagingInt(User::getAge));

 

運行結果:

 39.125

 

5）一次性得到元素的個數、總和、最大值、最小值

IntSummaryStatistics statistics = list.stream().collect(
Collectors.summarizingInt(User::getAge));

 

運行結果：

6）字符串拼接

要將用戶的姓名連成一個字符串並用逗號分割。

String names = list.stream().map(User::getName)
.collect(Collectors.joining(", "));

 

運行結果：

 鋼鐵俠, 鋼鐵俠, 蜘蛛俠, 趙麗穎, 詹姆斯, 李世民, 蔡徐坤, 葫蘆娃的爺爺

 

3.5 分組

在數據庫操作中，我們經常通過GROUP BY關鍵字對查詢到的數據進行分組，java8的流式處理也提供了分組的功能。使用Collectors.groupingBy來進行分組。

1）可以根據用戶所在城市進行分組

Map<String, List<User>> cityMap = list.stream()
.collect(Collectors.groupingBy(User::getAddress));

 

結果是一個map，key為不重複的城市名，value為屬於該城市的用戶列表。已經實現了分組。

2）二級分組，先根據城市分組再根據性別分組

Map<String, Map<Integer, List<User>>> group = list.stream().collect(
        Collectors.groupingBy(User::getAddress, // 一級分組，按所在地區
                Collectors.groupingBy(User::getSex))); // 二級分組，按性別

 

運行結果：

3）如果僅僅想統計各城市的用戶個數是多少，並不需要對應的list

按城市分組並統計人數：

Map<String, Long> cityCountMap = list.stream()
.collect(Collectors.groupingBy(User::getAddress,Collectors.counting()));

 

運行結果：

4）當然，也可以先進行過濾再分組並統計人數

Map<String,Long> map = list.stream().filter(user -> user.getAge() <= 30)
        .collect(Collectors.groupingBy(User::getAddress,Collectors.counting()));

 

運行結果：

5）partitioningBy 分區

分區與分組的區別在於，分區是按照 true 和 false 來分的，因此partitioningBy 接受的參數的 lambda 也是 T -> boolean

//根據年齡是否小於等於30來分區
Map<Boolean, List<User>> part = list.stream()
        .collect(partitioningBy(user -> user.getAge() <= 30));

 

運行結果：

總結

到目前為止，stream的功能我們已經用了很多了，感覺有點眼花繚亂卻無所不能，stream能做的事情遠遠不止這些。

我們可以多學習使用stream，把原來複雜的sql查詢，一遍又一遍地for循環的複雜代碼重構，讓代碼更簡潔易懂，可讀性強。

拓展閱讀：Redis專題（1）：構建知識圖譜

Redis專題(2)：Redis數據結構底層探秘

作者：楊亨

來源：宜信技術學院

【精選推薦文章】

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

想要讓你的商品在網路上成為最夯、最多人討論的話題?

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

不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

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

  今年2月，由光環新網運營的 AWS 中國（北京）區域和由西雲數據運營的 AWS 中國 （寧夏）區域發布新的實例類型，新的實例類型包括 C5、C5d、R5、R5d。除了這四種之外，在AWS國外部分區域還上線了最新的C5n。       這些新實例類型個個都具有鮮明的特徵，我簡單整理歸納如下：

• C5實例：性價比顯著提升（與 C4 實例相比，C5 實例提供了更高的內存與 vCPU 比率，並且性價比提高了 25%，某些應用程序提高了 50% 以上），更大的實例大小（C5 實例新的更大的實例 c5.18xlarge提供了 72 個 vCPU 和 144 GiB 內存並提供了 25 Gbps 的網絡帶寬）。
• C5d實例：基於本地 NVMe 的 SSD 磁盤將被物理連接到主機服務器，提供與C5實例的生命周期相耦合的塊級存儲。c5d.18xlarge 規格的實例支持2塊900GB的NVMe SSD作為本地存儲。
• C5n實例：這是C5 系列的最新成員，其c5n.18xlarge規格可提供高達 100Gbps 的網絡吞吐量。
• R5實例：其最大實例規格支持96 vCPU、768 GiB內存和25 Gbps 網絡帶寬。
• R5d實例：R5d 實例與 R5 實例規格相同，它還包括高達 3.6 TB 的本地 NVMe 存儲。

這些實例類型之所以如此實力超群，我認為主要歸功於兩點：

• 處理器升級

C5 實例配備 Intel Xeon Platinum 8000 系列 (Skylake-SP) 處理器，它發佈於2017/Q3，具有高達 3.4GHz 的穩定全核 Turbo CPU 時鐘速度，並使用 Intel Turbo Boost Technology 來允許單個核心睿頻高達3.5GHz。C5 實例為新的 Intel 高級矢量擴展 512 (AVX-512) 指令集提供了支持，與上一代 C4 實例相比，矢量和浮點計算性能提高最高可達2倍。
而發佈於2015年的C4 實例類型，配備Intel Xeon E5-2666 v3 (Haswell) 處理器。其時鐘頻率為2.9 GHz，配合Intel® Turbo Boost后最高可達3.5 GHz。

• 採用了AWS Nitro 虛擬化平台

AWS Nitro 將是這篇文章的主角。本文會從它的發展歷程、架構、所創造的價值等方面進行分析和介紹，試圖總結出AWS上虛擬化基礎平台發展的脈絡。

AWS EC2虛擬化發展歷程

下錶總結了AWS曾經採用的虛擬化技術，以及這些技術之間的性能對比：

 

• #1是全模擬技術。這種虛擬化方式能支持未修改的客戶機操作系統，但速度會嚴重下降。典型產品是VMware 在1986年發布的虛擬化產品。AWS 並沒有採用這種虛擬化技術，放在表格中只是為了做對比用。
• #2 是基於Xen的半虛擬化技術（Paravirtualization，PV）。PV 要求修改客戶機內核和驅動。EC2第一個採用半虛擬化的實例類型是 m1.small。
• #3 到 #6 是基於Xen和CPU硬件的全虛擬化技術（Hardware-assisted virtualization，HVM）。採用Xen HVM 技術的虛擬機運行在具有CPU和內存（VT-x）硬件虛擬化能力的處理器上，並使用半虛擬化驅動程序用於網絡和存儲設備。HVM 3.0 中尚未實現中斷和定時器半虛擬化，但在4.0中已有改善。
• #7 和 #8 則是AWS Nitro技術，這是AWS 研發的一種新虛擬化平台。後面會有詳細介紹。

過去幾年中，Xen是AWS上虛擬化技術的主體，業已成為業界標準之一，已經非常成熟。那麼，為什麼AWS要從Xen 向 Nitro 發展呢？這得從Xen 的架構說起。

從上圖可以看出，Xen 實現了虛擬機的CPU 和內存虛擬化，但是虛擬機的I/O 訪問，包括網絡和存儲等，都是通過虛擬機中的前端模塊和 dom0 中的後端模塊通信，然後由dom0 中的後端模塊通過設備驅動實現的。這I/O路徑太長，這降低了I/O性能，而且dom0還會和業務虛擬機搶佔宿主機資源，很難實現管理虛機和業務虛機之間的平衡，以及避免抖動。

2013年，AWS 採用 Xen PV虛擬化技術的cr1.8xlarge 實例的架構如下圖所示：

這是嚴格意義上未採用Nitro技術的最後一個EC2型號。簡要說明：

1. 圖中的硬件（Hardware），是運行虛擬機的物理服務器，採用了當時很強大的標準的10Gbps網卡，以及管理一些本地磁盤的存儲HBA卡。Hardware上既運行用戶的業務虛擬機，還運行Xen的dom0虛擬機。
2. VMM採用Xen項目的PV模式。
3. 圖中 Amzon Linux 代表Xen dom0，它負責訪問硬件，向虛擬機提供I/O 能力。

圖中 cr1.8xlarge 代表一個這種規格的虛擬機，它的本地存儲、EBS卷和VPC網絡訪問都是通過Xen管理的dom0 虛擬機實現的。

Nitro起源和發展

針對傳統虛擬化架構存在的問題，從2012年開始，AWS EC2虛擬化團隊就開始思考以下問題：

1. 能做出比純軟件架構更好的hypervisor嗎？
2. 設備模型本身很複雜，而且它會和業務虛擬機競爭CPU和系統資源，同時技術上它很難避免抖動發生
3. hypervisor太重了，能將hypervisor 和它周邊的組件解耦嗎？

  從成立之日起，AWS就善於聽取客戶的呼聲和建議，並不斷進行迭代式改進，而不是大刀闊斧地從頭設計一個新架構。根據該原則，AWS團隊首先從最難的網絡部分着手，其位置就是上圖中的金黃色虛線框所示位置。從2013年開始，一些EC2實例類型開始支持網絡接口的硬件虛擬化：單根I/O虛擬化（SR-IOV），而第一個是2013年1月發布的C3，它首次採用了AWS增強型網絡（enhanced networking）。這最初是通過ixgbe驅動程序實現的，速度高達10 Gbps。   c3.8xlarge的架構如下圖所示：

c3.8xlarge的架構與cr1.8xlarge相比，在宿主機上增加了一塊新網卡，這塊網卡和原有的標準網絡通過一個迴環線（loopback cable）連接起來。虛機VPC網絡功能不再通過Xen 的dom0 實現，而是直接訪問宿主機上的這塊硬件網卡。C3 是AWS EC2 歷史上增長最快的幾個實例類型之一，它尤其以控制性能抖動和持續的網絡性能著稱。這可以看做Nitro思想的發源，那就是將軟件功能卸載到專有硬件上。

  下一個改進方向是EBS存儲訪問性能提升。   2015年，AWS推出了C4實例類型，它針對EBS卷使用了硬件虛擬化技術。c4.8xlarge的架構如下圖所示。仔細對比能發現，這個新架構與C3中的網絡架構改進有些不同。在虛擬機中，還保留了“前端-後端”這種Xen傳統架構，這是當時為了兼容性和穩妥新考慮，因為NVMe在當時來說還是一種非常新的技術。在宿主機上，採用了新收購的Annapurna Labs公司開發一種卡(下圖中黃色虛線框內)，它能將遠端存儲以NMVe形式呈現給虛擬機。

這個改進的結果是，宿主機上的CPU被Xen佔用得少了，能更多地被虛機使用了。

  2016年5月發布的X1 是第一個支持ENA的實例類型。ENA是增強型網絡的最新實現，速度高達25 Gbps。ENA，全稱是Elastic Network Adapter，它正是Nitro項目的一部分，它是由Annapurna Labs公司開發的。

現在的ENA，能用於虛擬機和物理機，它以開源項目形式發布在github上。ENA 是AWS網絡虛擬化一關鍵技術，它使得虛擬機能夠繞過內核和用戶空間網絡處理程序，直接操作網卡硬件，這顯著提升了網絡效率。

從用戶使用角度，也許只是用了一個新網卡驅動。但是其底層採用了Annapurna Labs公司開發的定製網絡ASIC硬件卡。這是Nitro第一款真正的專用硬件卡。它不僅卸載了VPC網絡功能，還卸載了EBS 存儲網絡功能。因此這是一種完全的網絡負載卸載硬件。

 

下一步的優化方向在實例存儲上。2017年，AWS發布了存儲優化實例類型i3，它使用了SR-IOV和NVMe存儲驅動。這是AWS首次採用Annapurna Labs研發的Nitro存儲卡40202所管理的SSD磁盤，這些磁盤被直接映射給虛擬機，虛擬機通過NVME驅動來使用宿主機上的SSD磁盤。這能實現磁盤300萬以上的IOPS性能。Nitro 芯片負責包括磁盤監控、加密、QoS等職責。  

 

  顯然，到這時候為止，仍然剩下的問題只能是Xen 自身，以及它的管理功能部分了。Xen過於笨重，因為作為傳統 Hypervisor，它必須做很多事情 – 它必須保護物理硬件和 BIOS，它必須虛擬化 CPU，虛擬化存儲，虛擬化網絡，並提供豐富的管理功能。其管理性dom0虛擬機會搶佔業務虛機的系統資源。那到底能不能把Xen徹底替換掉呢？答案是肯定的，因為AWS在技術上從來沒讓人失望過。   2017年11月，AWS發布了C5 實例類型。它使用基於KVM的Nitro hypervisor 替換了Xen，hypervisor 軟件大大被簡化，Xen 所用的 dom0 也不需要了。其架構示意圖如下：

 

AWS Nitro 則重新構建了EC2虛擬化基礎架構。Nitro 系統將存儲、網絡和安全功能卸載（offload）到專用的硬件（Nitro卡）上，帶來的好處是虛擬化實例幾乎可以為客戶機操作系統提供主機的所有 CPU 和內存，同時Hypervisor 的功能也因此大大減弱。   Nitro 還被用到2017年發布的AWS 首個物理機實例類型 i3.metal中。下圖是i3.metal架構示意圖：

在i3.metal 中，Nitro 發揮了基礎性作用。它的安全芯片通過提供硬件保護和固件驗證功能為I3實例提供安全保障；它的各種卡，使得I3實例具備基於非易失性存儲器標準 (NVMe) SSD 的實例存儲，通過ENA支持高達 25Gbps 的聚合網絡帶寬。 

Nitro 架構

AWS Nitro 系統是模塊化組件的集合，可以使用廣泛的計算、存儲、內存和網絡選項來設計 EC2 實例，為新一代EC2實例提供動力。它包括三大部分：

 

Nitro 卡

 

這些Nitro 卡是硬件，插入到宿主機的PCIe卡槽中，採用SR-IOV 直通（passthrough）技術將這些卡呈現給實例。包括：

• VPC Data Plane（用於VPC訪問的Nitro卡）：本質上是一塊通過PCIe附加到宿主機上的一塊定製網卡，支持網絡封包和解包、安全組、限速器和路由等功能。實例通過ENA驅動和它通信。同時，該卡還帶有一些網絡加速功能。以限速器為例，每個Nitro支持的實例，不管它在哪個區域哪個數據中心哪個宿主機上，都會有一致的性能，這對分佈式應用非常重要。
• EBS Data Plane（用於EBS卷訪問的Nitro卡）：本質上是一塊通過PCIe附加到宿主機上的一塊定製卡。通過該卡，遠端存儲被以NVMe設備形式展現給實例，實例通過標準NVMe驅動程序訪問該卡。它首次被用在C4中。支持卷加密、存儲加速；支持I3裸機實例。
• Instance Storage Data Plane（用於實例存儲訪問的Nitro卡）：通過該卡，本地磁盤被以NVMe設備形式展現給實例，實例通過標準NVMe驅動程序訪問這些磁盤。支持加密、限速器和本地磁盤監控。

除了卡之外，Nitro 還提供卡控制器（Card Controller）。它提供API端點，負責協調所有Nitro卡、Nitro Hypervisor和Nitro安全芯片。它還利用Nitro安全芯片實現了Hardware Root Of Trust（硬件信任根），支持實例監控、計量和認證。它還為Nitro EBS卡實現了NVMe控制器。

Nitro 安全芯片

Nitro安全芯片整合到宿主機主板中，控制對所有非易失性存儲的訪問，持續監控和保護硬件資源，並在每次系統啟動時獨立驗證固件。

Nitro hypervisor

Nitro hypervisor位於極簡化的定製的Linux 內核中，基於KVM，帶有定製的VMM和小用戶空間應用。它只負責管理內存和CPU分配，將Nitro卡虛擬功能分配給實例，監控和計量硬件等，不再需要提供任何網絡功能。因此它只需執行虛擬機所需指令，快速而且簡單，在大多數工作負載中能提供接近裸機的性能。 Nitro 各組件之間的關係如下圖所示:

 

Nitro 帶來的豐富價值

更高網絡訪問性能

利用Nitro提供的新一代 Elastic Network Adapter (ENA) 和 NVM Express (NVMe) 技術，C5 實例提供了高達 25 Gbps 的網絡帶寬和更低延遲及抖動。2018年發布的更強大變體 C5n 實例，支持網絡帶寬高達 100 Gbps，用戶的仿真、內存緩存、數據湖以及其他通訊密集型應用運行得將比以往更好。   採用Nitro增強網絡功能后的網絡延遲對比：

（Series 1：cc2.8xlarge，2：c3.8xlarge，3：c4.8xlarge，4：c5.18xlarge，5：c5.18xlarge（採用ENAv2））

網絡和存儲帶寬對比:   (1:c3.8xlarge,2:c4.8xlarge,3:c5.18xlarge,4:c5n.18xlarge. Series1:網絡，Series2：存儲)

更高EBS和本地存儲訪問性能

Nitro 使得實例可通過物理方式連接到主機服務器的基於 NVMe 的本地 SSD 塊級存儲，以及將遠端存儲以NVMe設備的形式呈現給實例。 2019年3月，由Nitro支撐的新計算密集型 C5 和 C5d 實例已經在AWS 北京和寧夏區域推出。C5實例支持高達9Gbps 的專用 Amazon EBS 帶寬。而 C5d 最大實例規格則可使用兩塊900G的NVMe SSD。這些實例非常適合需要訪問高速、低延遲的本地存儲的應用程序。

更大實例大小和CPU內存比率

由Nitro支撐的C5實例，其實例的CPU和內存比率，由C4的1：1.875上升到1：2；實例的最大規格，從C4的36vCPU/60Gib內存，上升到72vCPU/144Gib內存。

更低虛擬化花銷

Nitro Hypervisor 是一款輕薄的靜態的虛擬機管理程序，可管理虛擬機的內存和CPU分配，並提供與大多數工作負載無法區分的性能。據Netflix公司Brendan Gregg 觀察，Nitro Hypervisor的性能損耗非常小，通常不到1％，他的結論是 Nitro提供的虛擬化性能接近裸設備。

更低Hypervisor抖動

有了Nitro后，就不再需要為存儲和網絡I/O再預留CPU和內存資源了。這不僅使得可以向EC2實例分配更多資源，為更大的實例規格提供了可能，還為實現一個簡單的輕量的hypervisor提供了可能，而這就為實現更低hypervisor抖動創造了條件。   下圖是一AWS 客戶在三種EC2實例上採用對延遲要求極低的一實時應用做的對比測試。藍色是C5，紅色是i3.metal，黃色是C4。SLA 是用於測試的實時應用所能忍受的最高延遲。

 

從上圖中的測試結果看，C5 相對裸機只有一點極小的附加開銷，而且性能非常平穩，幾乎沒有波動，能完全滿足應用的SLA需求。而C4則有相對較大的波動，只能大概滿足70的SLA。

更多實例類型

AWS發布了基於Nitro的實例存儲實例類型 C5d，M5d 和 R5d，提供低延遲高吞吐的基於NVMe的實例存儲。 AWS在2017 re：Invent上宣布了基於Nitro的AWS EC2 Bare Metal實例 I3.metal。它沒有性能開銷，能夠運行你喜歡的任何東西，比如Xen，KVM，容器，ESXi，FireCracker微虛機等；支持非虛擬化環境，支持容器環境，同時還能繼續使用比如EBS、ELB和VPC等基礎服務；支持比如SAP HANA和其它內存型應用。 AWS還基於Nitro發布了採用AMD EPYC處理器的系列實例R5，M5和T3，最高可降低10%成本。 AWS發布了基於Nitro的具有100Gbps網絡帶寬的實例類型C5n，這是運行HPC和分佈式機器學習負載的理想類型。 AWS發布了基於Nitro的採用AWS Graviton（基於ARM）處理器的實例類型A1，最高可降低45%成本。

更低價格、更高性價比

下錶显示了AWS 北京（BJS）和中衛（ZHY）區域的4代和5代EC2實例的價格比較，你可以看到實實在在的價格下降：  

 

目前，Nitro支撐的C5 實例提供了 EC2 產品系列中最佳的價格/計算性能比。與C4實例相比，其性價比提高了49% 。 與R4實例相比，由Nitro支撐的R5實例為每個vCPU提供額外5%的內存，且每 GiB 價格低50%。R5實例非常適用於高性能數據庫、分佈式內存緩存、內存數據庫和大數據分析等應用程序。

為更多性能優化提供了可能

對於需要深度定製化EC2 的用戶而言，Nitro 還帶了了另外的好處：對於EC2 更深入的監控和優化。在由Nitro支撐的C5實例中，你可以得到數百個PMC 計數器（Performance Monitoring Counters ，性能監控計數器）。作為對比，以前的實例類型中，你只能看到區區7個PMCs。更多的PMC計數器，為性能優化提供了更多可能。

小結

亞馬遜 AWS CTO 沃納·威格爾（Werner Vogels）曾經說過，“在亞馬遜 AWS，我們90%到95%的新項目都是基於客戶給我們的反饋，剩下5%也是從客戶角度出發所做得創新嘗試。”而Nitro 正是這種項目之一，它誕生於2013年，成年於2017年，現在還在不斷成長中。Nitro 正在作為AWS核心虛擬化架構平台，推動着AWS最核心的EC2產品家族不斷往更大（單實例的vCPU和內存更大）、更快（I/O速度更快）、更安全（採用Nitro安全芯片）、更穩定（Hypervisor抖動更低）、更多類型、更高性價比方向演進，支撐越來越多用戶越來越多的業務場景，創造着越來越大的業務價值。     主要參考文檔：

1. AWS re:Invent 2018: Powering Next-Gen EC2 Instances: Deep Dive into the Nitro System (CMP303-R1)
2. AWS re:Invent 2017: C5 Instances and the Evolution of Amazon EC2 Virtualization (CMP332)
3. AWS re:Invent 2018: Deep Dive on Amazon EC2 Instances & Performance Optimization Best Practices （CMP307）
4. AWS re:Invent 2018:Optimizing Network Performance for Amazon EC2 Instances (CMP308-R1) 

感謝您的閱讀，歡迎關注我的微信公眾號：

 

【精選推薦文章】

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

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

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

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

我周圍的人幾乎都認為二分查找很簡單，但事實真的如此嗎？二分查找真的很簡單嗎？並不簡單。看看 Knuth 大佬（發明 KMP 算法的那位）怎麼說的：

Although the basic idea of binary search is comparatively straightforward, the details can be surprisingly tricky…

這句話可以這樣理解：思路很簡單，細節是魔鬼。

本文就來探究幾個最常用的二分查找場景：尋找一個數、尋找左側邊界、尋找右側邊界。

而且，我們就是要深入細節，比如while循環中的不等號是否應該帶等號，mid 是否應該加一等等。分析這些細節的差異以及出現這些差異的原因，保證你能靈活準確地寫出正確的二分查找算法。

一、二分查找的框架

int binarySearch(int[] nums, int target) {
    int left = 0, right = ...;

    while(...) {
        int mid = (right + left) / 2;
        if (nums[mid] == target) {
            ...
        } else if (nums[mid] < target) {
            left = ...
        } else if (nums[mid] > target) {
            right = ...
        }
    }
    return ...;
}

分析二分查找的一個技巧是：不要出現 else，而是把所有情況用 else if 寫清楚，這樣可以清楚地展現所有細節。本文都會使用 else if，旨在講清楚，讀者理解后可自行簡化。

其中…標記的部分，就是可能出現細節問題的地方，當你見到一個二分查找的代碼時，首先注意這幾個地方。後文用實例分析這些地方能有什麼樣的變化。

另外聲明一下，計算 mid 時需要技巧防止溢出，建議寫成: mid = left + (right – left) / 2，本文暫時忽略這個問題。

二、尋找一個數（基本的二分搜索）

這個場景是最簡單的，可能也是大家最熟悉的，即搜索一個數，如果存在，返回其索引，否則返回 -1。

int binarySearch(int[] nums, int target) {
    int left = 0; 
    int right = nums.length - 1; // 注意

    while(left <= right) { // 注意
        int mid = (right + left) / 2;
        if(nums[mid] == target)
            return mid; 
        else if (nums[mid] < target)
            left = mid + 1; // 注意
        else if (nums[mid] > target)
            right = mid - 1; // 注意
        }
    return -1;
}

1. 為什麼 while 循環的條件中是 <=，而不是 < ？

答：因為初始化 right 的賦值是 nums.length – 1，即最後一個元素的索引，而不是 nums.length。

這二者可能出現在不同功能的二分查找中，區別是：前者相當於兩端都閉區間 [left, right]，後者相當於左閉右開區間 [left, right)，因為索引大小為 nums.length 是越界的。

我們這個算法中使用的是 [left, right] 兩端都閉的區間。這個區間就是每次進行搜索的區間，我們不妨稱為「搜索區間」(search space)。

什麼時候應該停止搜索呢？當然，找到了目標值的時候可以終止：

    if(nums[mid] == target)
        return mid; 

但如果沒找到，就需要 while 循環終止，然後返回 -1。那 while 循環什麼時候應該終止？搜索區間為空的時候應該終止，意味着你沒得找了，就等於沒找到嘛。

while(left <= right)的終止條件是 left == right + 1，寫成區間的形式就是 [right + 1, right]，或者帶個具體的数字進去 [3, 2]，可見這時候搜索區間為空，因為沒有数字既大於等於 3 又小於等於 2 的吧。所以這時候 while 循環終止是正確的，直接返回 -1 即可。

while(left < right)的終止條件是 left == right，寫成區間的形式就是 [right, right]，或者帶個具體的数字進去 [2, 2]，這時候搜索區間非空，還有一個數 2，但此時 while 循環終止了。也就是說這區間 [2, 2] 被漏掉了，索引 2 沒有被搜索，如果這時候直接返回 -1 就可能出現錯誤。

當然，如果你非要用 while(left < right) 也可以，我們已經知道了出錯的原因，就打個補丁好了：

//...
while(left < right) {
    // ...
}
return nums[left] == target ? left : -1;

2. 為什麼 left = mid + 1，right = mid – 1？我看有的代碼是 right = mid 或者 left = mid，沒有這些加加減減，到底怎麼回事，怎麼判斷？

答：這也是二分查找的一個難點，不過只要你能理解前面的內容，就能夠很容易判斷。

剛才明確了「搜索區間」這個概念，而且本算法的搜索區間是兩端都閉的，即 [left, right]。那麼當我們發現索引 mid 不是要找的 target 時，如何確定下一步的搜索區間呢？

當然是去搜索 [left, mid – 1] 或者 [mid + 1, right] 對不對？因為 mid 已經搜索過，應該從搜索區間中去除。

3. 此算法有什麼缺陷？

答：至此，你應該已經掌握了該算法的所有細節，以及這樣處理的原因。但是，這個算法存在局限性。

比如說給你有序數組 nums = [1,2,2,2,3]，target = 2，此算法返回的索引是 2，沒錯。但是如果我想得到 target 的左側邊界，即索引 1，或者我想得到 target 的右側邊界，即索引 3，這樣的話此算法是無法處理的。

這樣的需求很常見。你也許會說，找到一個 target 索引，然後向左或向右線性搜索不行嗎？可以，但是不好，因為這樣難以保證二分查找對數級的時間複雜度了。

我們後續的算法就來討論這兩種二分查找的算法。

三、尋找左側邊界的二分搜索

直接看代碼，其中的標記是需要注意的細節：

int left_bound(int[] nums, int target) {
    if (nums.length == 0) return -1;
    int left = 0;
    int right = nums.length; // 注意

    while (left < right) { // 注意
        int mid = (left + right) / 2;
        if (nums[mid] == target) {
            right = mid;
        } else if (nums[mid] < target) {
            left = mid + 1;
        } else if (nums[mid] > target) {
            right = mid; // 注意
        }
    }
    return left;
}

1. 為什麼 while(left < right) 而不是 <= ?

答：用相同的方法分析，因為初始化 right = nums.length 而不是 nums.length – 1 。因此每次循環的「搜索區間」是 [left, right) 左閉右開。

while(left < right) 終止的條件是 left == right，此時搜索區間 [left, left) 恰巧為空，所以可以正確終止。

2. 為什麼沒有返回 -1 的操作？如果 nums 中不存在 target 這個值，怎麼辦？

答：因為要一步一步來，先理解一下這個「左側邊界」有什麼特殊含義：

對於這個數組，算法會返回 1。這個 1 的含義可以這樣解讀：nums 中小於 2 的元素有 1 個。

比如對於有序數組 nums = [2,3,5,7], target = 1，算法會返回 0，含義是：nums 中小於 1 的元素有 0 個。如果 target = 8，算法會返回 4，含義是：nums 中小於 8 的元素有 4 個。

綜上可以看出，函數的返回值（即 left 變量的值）取值區間是閉區間 [0, nums.length]，所以我們簡單添加兩行代碼就能在正確的時候 return -1：

while (left < right) {
    //...
}
// target 比所有數都大
if (left == nums.length) return -1;
// 類似之前算法的處理方式
return nums[left] == target ? left : -1;

3. 為什麼 left = mid + 1，right = mid ？和之前的算法不一樣？

答：這個很好解釋，因為我們的「搜索區間」是 [left, right) 左閉右開，所以當 nums[mid] 被檢測之後，下一步的搜索區間應該去掉 mid 分割成兩個區間，即 [left, mid) 或 [mid + 1, right)。

4. 為什麼該算法能夠搜索左側邊界？

答：關鍵在於對於 nums[mid] == target 這種情況的處理：

    if (nums[mid] == target)
        right = mid;

可見，找到 target 時不要立即返回，而是縮小「搜索區間」的上界 right，在區間 [left, mid) 中繼續搜索，即不斷向左收縮，達到鎖定左側邊界的目的。

5. 為什麼返回 left 而不是 right？

答：返回left和right都是一樣的，因為 while 終止的條件是 left == right。

四、尋找右側邊界的二分查找

尋找右側邊界和尋找左側邊界的代碼差不多，只有兩處不同，已標註：

int right_bound(int[] nums, int target) {
    if (nums.length == 0) return -1;
    int left = 0, right = nums.length;

    while (left < right) {
        int mid = (left + right) / 2;
        if (nums[mid] == target) {
            left = mid + 1; // 注意
        } else if (nums[mid] < target) {
            left = mid + 1;
        } else if (nums[mid] > target) {
            right = mid;
        }
    }
    return left - 1; // 注意

1. 為什麼這個算法能夠找到右側邊界？

答：類似地，關鍵點還是這裏：

    if (nums[mid] == target) {
        left = mid + 1;

當 nums[mid] == target 時，不要立即返回，而是增大「搜索區間」的下界 left，使得區間不斷向右收縮，達到鎖定右側邊界的目的。

2. 為什麼最後返回 left – 1 而不像左側邊界的函數，返回 left？而且我覺得這裏既然是搜索右側邊界，應該返回 right 才對。

答：首先，while 循環的終止條件是 left == right，所以 left 和 right 是一樣的，你非要體現右側的特點，返回 right – 1 好了。

至於為什麼要減一，這是搜索右側邊界的一個特殊點，關鍵在這個條件判斷：

    if (nums[mid] == target) {
        left = mid + 1;
        // 這樣想: mid = left - 1

因為我們對 left 的更新必須是 left = mid + 1，就是說 while 循環結束時，nums[left] 一定不等於 target 了，而 nums[left – 1]可能是target。

至於為什麼 left 的更新必須是 left = mid + 1，同左側邊界搜索，就不再贅述。

3. 為什麼沒有返回 -1 的操作？如果 nums 中不存在 target 這個值，怎麼辦？

答：類似之前的左側邊界搜索，因為 while 的終止條件是 left == right，就是說 left 的取值範圍是 [0, nums.length]，所以可以添加兩行代碼，正確地返回 -1：

while (left < right) {
    // ...
}
if (left == 0) return -1;
return nums[left-1] == target ? (left-1) : -1;

五、最後總結

先來梳理一下這些細節差異的因果邏輯：

第一個，最基本的二分查找算法：

因為我們初始化 right = nums.length - 1
所以決定了我們的「搜索區間」是 [left, right]
所以決定了 while (left <= right)
同時也決定了 left = mid+1 和 right = mid-1

因為我們只需找到一個 target 的索引即可
所以當 nums[mid] == target 時可以立即返回

第二個，尋找左側邊界的二分查找：

因為我們初始化 right = nums.length
所以決定了我們的「搜索區間」是 [left, right)
所以決定了 while (left < right)
同時也決定了 left = mid+1 和 right = mid

因為我們需找到 target 的最左側索引
所以當 nums[mid] == target 時不要立即返回
而要收緊右側邊界以鎖定左側邊界

第三個，尋找右側邊界的二分查找：

因為我們初始化 right = nums.length
所以決定了我們的「搜索區間」是 [left, right)
所以決定了 while (left < right)
同時也決定了 left = mid+1 和 right = mid

因為我們需找到 target 的最右側索引
所以當 nums[mid] == target 時不要立即返回
而要收緊左側邊界以鎖定右側邊界

又因為收緊左側邊界時必須 left = mid + 1
所以最後無論返回 left 還是 right，必須減一

如果以上內容你都能理解，那麼恭喜你，二分查找算法的細節不過如此。

通過本文，你學會了：

1. 分析二分查找代碼時，不要出現 else，全部展開成 else if 方便理解。

2. 注意「搜索區間」和 while 的終止條件，如果存在漏掉的元素，記得在最後檢查。

3. 如需要搜索左右邊界，只要在 nums[mid] == target 時做修改即可。搜索右側時需要減一。

就算遇到其他的二分查找變形，運用這幾點技巧，也能保證你寫出正確的代碼。LeetCode Explore 中有二分查找的專項練習，其中提供了三種不同的代碼模板，現在你再去看看，很容易就知道這幾個模板的實現原理了。

【精選推薦文章】

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

想要讓你的商品在網路上成為最夯、最多人討論的話題?

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

不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

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

一 Kubernetes dashboard簡介

1.1 Web UI簡介

dashboard是基於Web的Kubernetes用戶界面。可以使用dashboard將容器化應用程序部署到Kubernetes集群，對容器化應用程序進行故障排除，以及管理集群資源。可以使用dashboard來概述群集上運行的應用程序，以及創建或修改單個Kubernetes資源（例如部署、任務、守護進程等）。可以使用部署嚮導擴展部署，啟動滾動更新，重新啟動Pod或部署新應用程序。
dashboard還提供有關群集中Kubernetes資源狀態以及可能發生的任何錯誤的信息。

二 dashboard部署

2.1 下載yaml

  1 [root@master ~]# mkdir dashboard					#建議將yaml存儲到本地
  2 [root@master ~]# cd dashboard/
  3 [root@master dashboard]# wget https://raw.githubusercontent.com/kubernetes/dashboard/master/aio/deploy/recommended/kubernetes-dashboard.yaml

 

2.2 修改為國內源

  1 [root@master ~]# cd dashboard/
  2 [root@master dashboard]# vi kubernetes-dashboard.yaml
  3 ……
  4 image: mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1
  5 ……

 
提示：將yaml文件中的image字段修改為mirrorgooglecontainers/kubernetes-dashboard-amd64:v1.10.1。

2.3 安裝

  1 [root@master dashboard]# kubectl apply -f kubernetes-dashboard.yaml
  2 [root@master ~]# kubectl get pod --all-namespaces -o wide| grep kubernetes-dashboard			#確認驗證
  3 kube-system	kubernetes-dashboard-68ddcc97fc-c5thv	0/1	Running	0	30s	<none>	node2	<none>	<none>

 

三 dashboard訪問方式

3.1 訪問方式概述

安裝dashboard后，需要為用戶配置對群集資源的訪問控制。從版本1.7開始，dashboard不再具有默認授予的完全管理員權限。默認所有權限都被撤銷，並且只授予了使Dashboard工作所需的最小權限。
提示：本說明僅針對使用Dashboard 1.7及更高版本的用戶。如果確信dashboard需要授予管理員權限，可參考：《附006.Kubernetes身份認證》
通常，其他應用程序不應直接訪問dashboard。
dashboard有以下三種訪問方式：
kubectl proxy：只能在localhost上訪問。訪問地址：http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
NodePort：編輯 kubernetes-dashboard.yaml文件中，將 type: ClusterIP 改為 type: NodePort，確認dashboard運行在哪個節點后。訪問地址：https://<node-ip>:<nodePort>
apiserver：需要在瀏覽器中安裝用戶證書。訪問地址： https://<master-ip>:<apiserver-port>/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
提示：kubectl proxy方式不推薦，建議使用有效證書來建立安全的HTTPS連接。

3.2 kubectl proxy

  1 [root@master ~]# kubectl proxy
  2 [root@master ~]# curl http://127.0.0.1:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/	#訪問

 
提示：建議通過後端形式，並且允許所有主機訪問的方式：

  1 [root@master ~]# nohup kubectl proxy --address='0.0.0.0' --accept-hosts='^*$' &

3.3 NodePort

NodePort訪問儀錶板的方式僅建議用於單節點設置中的Kubernetes環境。

  1 [root@master ~]# kubectl -n kube-system edit service kubernetes-dashboard
  2 ……
  3    type: NodePort
  4 ……
  5 #將type: ClusterIP  修改為 type: NodePort。

 
提示：以上操作也可通過以下命令一步完成：

  1 [root@master ~]# kubectl get pods --namespace=kube-system | grep dashboard
  2 kubernetes-dashboard-68ddcc97fc-c5thv   1/1     Running   0          3h14m
  3 [root@master ~]# kubectl describe pod kubernetes-dashboard-68ddcc97fc-c5thv --namespace=kube-system | grep Node
  4 Node:               node2/172.24.8.73

 
測試訪問：
瀏覽器訪問：http://172.24.8.73:30343/
提示：若部署的Kubernetes集群為多節點集群，需要通過以上方式查找dashboard所在的node節點，若為單節點集群，則直接訪問http://<master>:<port>即可。

3.4 apiserver

若Kubernetes API服務器公開並可從外部訪問，可瀏覽器直接訪問：https://172.24.8.71:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
注意：apiserver默認情況下使用system:anonymous用戶進行訪問，因此沒有權限打開相應資源。只有在選擇在瀏覽器中安裝用戶證書時，才能使用這種訪​​問儀錶板的方式。
NodePort和apiserver都需要配置相應的認證才可訪問，確定某種方式方式后需要配置認證類型。

3.5 Ingress

dashboard也可以使用ingress進行資源公開。
可參考：https://kubernetes.io/docs/concepts/services-networking/ingress/

四 dashboard驗證方式

瀏覽器訪問的時候需要加載相應證書，部署完成后默認已經創建相應證書，可參考附01進行導出。由於Kubernetes默認證書可能過期導致無法訪問dashboard，本實驗在已成功部署Kubernetes後手動重新創建證書。

4.1 創建證書

  1 [root@master ~]# mkdir /etc/kubernetes/dash_pki
  2 [root@master ~]# cd /etc/kubernetes/dash_pki/
  3 [root@master dash_pki]# openssl genrsa -out ca.key 2048				#生成一個 2048 bit 的 ca.key
  4 [root@master dash_pki]# openssl req -x509 -new -nodes -key ca.key -subj "/CN=172.24.8.71" -days 10000 -out ca.crt	                #根據 ca.key 生成一個 ca.crt（使用 -days 設置證書的有效時間）
  5 [root@master dash_pki]# openssl genrsa -out server.key 2048			        #生成一個 2048 bit 的 server.key
  6 [root@master dash_pki]# openssl req -new -key server.key -subj "/CN=172.24.8.71" -out server.csr			                #根據 server.key 生成一個 server.csr
  7 [root@master dash_pki]# openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000	#根據 ca.key、ca.crt 和 server.csr 生成 server.crt
  8 subject=/CN=172.24.8.71
  9 Getting CA Private Key
 10 [root@master dash_pki]# openssl x509  -noout -text -in ./server.crt		        #查看證書

 

4.2 修改默認證書配置

  1 [root@master ~]# cd dashboard/
  2 [root@master dashboard]# kubectl delete -f kubernetes-dashboard.yaml		#刪除使用默認證書所創建的dashboard
  3 [root@master dashboard]# ll /etc/kubernetes/dash_pki/
  4 [root@master dashboard]# kubectl create secret generic kubernetes-dashboard-certs --from-file="/etc/kubernetes/dash_pki/server.crt,/etc/kubernetes/dash_pki/server.key" -n kube-system	#掛載新證書到dashboard
  5 [root@master dashboard]# kubectl get secret kubernetes-dashboard-certs -n kube-system -o yaml	#查看新證書

 

4.3 重新部署dashboard

  1 [root@master dashboard]# kubectl apply -f kubernetes-dashboard.yaml
  2 [root@master dashboard]# kubectl get pods --namespace=kube-system | grep dashboard		#確認驗證

 

4.4 導入證書

將server.crt導入IE瀏覽器，導入操作略。

4.5 訪問測試

本試驗基於apiserver訪問方式+Kubeconfig身份驗證進行登錄。
通過apiserver形式訪問：https://172.24.8.71:6443/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/
提示：dashboard登錄整個流程可參考：https://www.cnadn.net/post/2613.htm
提示：apiserver方式見3.4，Kubeconfig驗證方式見《附006.Kubernetes身份認證》中的3.5。  

附001：導出當前Kubernetes證書

[root@master ~]# grep ‘client-certificate-data’ ~/.kube/config | head -n 1 | awk ‘{print $2}’ | base64 -d >> kubecfg.crt
[root@master ~]# grep ‘client-key-data’ ~/.kube/config | head -n 1 | awk ‘{print $2}’ | base64 -d >> kubecfg.key
[root@master ~]# openssl pkcs12 -export -clcerts -inkey kubecfg.key -in kubecfg.crt -out k8s.crt -name “kubernetes-client”
Enter Export Password:[x120952576]
Verifying – Enter Export Password:[x120952576]
使用相應的密碼，將k8s.crt導入IE瀏覽器，導入操作略。    
我的博客即將同步至騰訊雲+社區，邀請大家一同入駐：https://cloud.tencent.com/developer/support-plan?invite_code=20stclch1nfo4

【精選推薦文章】

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

想知道網站建置、網站改版該如何進行嗎?將由專業工程師為您規劃客製化網頁設計及後台網頁設計

帶您來看台北網站建置，台北網頁設計，各種案例分享

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

本文繼20年研發管理經驗談（十）。

此文是對我個人測試思想的一個總結，由於經驗不夠，知識淺薄，如果有什麼不合理的地方請一笑了之。

一、面向對象的概念
　　所謂的面向對象是軟件開發的一種重要的思維方式，是把軟件開發過程中出現的事物,用一個個的對像來分析.一般一張數據表可以封裝為一個對像。用個形象的比喻：我們現在要做一張桌子，首先我們考慮到的是我們要做的是什麼？是桌子；桌子是用來干什麼的呢？是用來吃飯、喝茶、看書、打麻將的；然後就要考慮桌子由哪些部分組成？由桌面和桌腿來組成；接着我們需要考慮我們採用什麼材料呢？紙？不行…那可什麼都幹不成，OK，用木頭；接着就可以開始把組成桌子的組件做為對象開始分析–桌面如何做是用刀砍的還是用刨子刨呢？桌腿又如何做…
　　一套完整的方法成形了就可以具體實現了，在做的過程中桌面要做多大，桌腿要做多長都要事先考慮到是不是要留出接口，這些就是我們給組成桌子的組件賦予的屬性。OK，現在可以做出具體的實物了，做好實物組件（對象）以後就要將做好的桌面桌腿進行組裝，由於我們事先考慮好了組件的屬性，考慮到了必須預留接口，因此我們可以很輕易的組合成功，桌子做出來了。以上就是面向對象的思想的一個簡要的比喻

　　了解面向對象必須了解的幾個名詞：對象、方法、屬性、繼承、多態。

 

二、遊戲測試
　　遊戲測試是整個軟件測試行業中比較特殊的一部份，他有着大多數軟件測試的共性，也具備自身的特性，而相對於許多通用軟件的測試來說，遊戲測試所具備的特性是非常明顯的。現在就簡要的說說上面提到的共性和特性。
共性：
1、測試的目的就是為了盡可能的發現軟件存在和潛在的問題。
2、測試都是需要測試人員按照產品行為描述來實施。產品行為描述可以是書面的規格說明書、需求文檔、產品文件、或是用戶手冊、源代碼、或是工作的可執行程序。
3、每一種測試都需要產品運行於真實的或是模擬環境之下。
4、每一種測試都要求以系統方法展示產品功能， 以證明測試結果是否有效， 以及發現其中出錯的原因， 從而讓程序人員進行改進。
總之，軟件測試就是對產品進行盡可能的全面檢查，盡可能的發掘bug，提高軟件質量，從而為企業創造利潤。

特性：
　　網絡遊戲世界從某種意義上說是另一個人類社會，只是人們在網絡遊戲世界中進行着在被允許的範圍內的活動，包括了修鍊、交流、合作、經商、欺詐、情感、衝突等等。而在遊戲製作時這些進行這些行為的部分就是一個個完整的功能，我們在進行測試的時候，需要考慮的不僅僅是能否實現功能，要考慮更多的是人們在進行操作時會如何做，可能有多少種做法，這些做法應該有什麼樣的響應，哪些做法是被禁止的，在進行了被禁止的操作后應該有什麼的響應。因此這裏就是涉及到了遊戲世界的測試方法：
1、遊戲情節的測試，主要指遊戲世界中的任務系統的組成， 有人也稱為遊戲世界的事件驅動， 我喜歡稱為遊戲情感世界的測試。
2、遊戲世界的平衡測試，主要表現在經濟平衡,能力平衡（ 包含技能， 屬性等等）,保證遊戲世界競爭公平。
3、遊戲文化的測試，比如整個遊戲世界的風格， 是中國文化主導,還是日韓風格等等，大到遊戲整體，小到N P C（ 遊戲世界人物） 對話， 比如一個書生，他的對話就必需斯文， 不可以用江湖語言。

以上陳述中關於遊戲特性的部分概念是曾在金山公司的測試人陳衛俊提出來過的,在此引用。

 

三、如何用面向對象的思想進行測試
　　上面了解了面向對象的概念以及遊戲測試和通用軟件測試的區別以後我們可以進入正題了—如何用面向對象的思想進行遊戲測試?
　　首先,和所有通用軟件以及硬件產品一樣,我們的遊戲是一個產品,是一個存在的實體,因此,我們把這個”實體”當做一個大的對象開始分析,整個遊戲由哪些部分構成,而構成整個遊戲的大的部分又由哪些組件構成,認真分析完這些以後就可以着手進行測試了,注意,這裏說”可以進行測試了”意思不是馬上就能進入測試,聽我慢慢道來。 
　　”工欲善其事,必先利其器”—某位高人說的,我們做測試也是一樣,分析完畢后,我們要做的還是分析 ^_^ 不過這裏的分析和之前的分析有點點區別,這裏我們需要分析的是具體功能的關鍵測試點和風險點,測試不能盲目,打蛇要打七寸…..在這裏我們就是把某個具體的功能作為一個對象，我們要分析組成這個功能的是哪些因素，一共有哪些測試點，哪些測試點是關鍵點，哪些是高風險點，一一列舉出來,這樣我們就一目瞭然了，然後就是我們打算採用何種方式來進行測試，這裏就是方法了.測試的方式可能有很多種(比如在不同的操作系統下進行測試等),因此我們也需要一一列舉，此外我們需要分析的還有測試過程中我們需要用到的具體測試手法、具體的數值、特定的環境等等這些就是屬性，當然這些我們也必須整理出來。
　　將以上提到的對象、方法、屬性整理成文檔就是我們測試時所必須的測試用例了。當然，還是老話，測試用例的優劣是以覆蓋面來評判的，這裏就需要經驗了，簡單說就是靠累積以及學習。
　　OK，測試用例我們完成了，剩下的就是實施測試了，實施測試時個人覺得一定要按照用例的描述去執行，如果在測試過程中覺得用例不完善可以先更新用例再進行測試，一定不要先測試再補用例！！
　　接下來就是測試報告，報告中包含的應該有所有測試點的簡述，包括了通過測試的部分和存在bug的部分。bug管理是很重要的一環，在這裏不詳述。
　　關於測試流程在這裏就不做具體說明，在這裏希望闡述的是一種測試的思想，個人覺得測試除了要有紮實的相關基礎知識以便更深入的了解產品以外，更重要的是測試思想，具備了完善的測試思想才能有計劃的完成每一步測試，從而提高測試的效率，保證測試產出的質量，也更好的保證產品的質量。面向對象是一種思想，用面向對象的思想來組織、計劃、實施測試工作，能讓我們在測試工作中有很強的目的性，他能清楚地告訴我們今天要做什麼，明天要做什麼，我們要做的是哪些，說回遊戲測試，遊戲開發是一個迭帶的開發模式，因此測試工作往往會有很大的隨機性，因此當我們接到一個新功能時，首先要明確我們要測得這個功能是做什麼的，有什麼用，這個功能怎麼使用。OK，我們了解了這個功能是什麼，能做什麼就可以開始細化分析了：這個功能共由哪些子功能組成，這些子功能是否有自己的子功能點，一層層的分析下去，然後就是從最底層的功能點分析：這個功能什麼情況下要發揮其功效，發揮其功效的因素有哪些，怎麼樣去發揮具體的功效，該功能有沒有相應的容錯機制，這些就是我們的詳細測試點和測試手法。然後向上一層一層分析，一直到最頂層就是我們的功能完整的測試方針。這樣我們就把面向對象的思想完全用到了測試中。當然，在分析的過程中我們必須考慮到，與遊戲情節、遊戲風格、遊戲平衡、玩家的易用性是否衝突等等因素，適時地給策劃提出正確的建議。

　　以上陳述的種種，無非是想將面向對象的思想用到測試中的好處列舉出來，或許經驗淺薄說的有些蒼白，但是我堅信一點，測試是一種思想，是一種絕對不亞於開發思想的學問，要想做好測試就需要具備良好的測試思想，或者良好的測試思想不是一天两天能夠形成的但是相信只要把測試當做一種職業，當作一種事業來做，把自己真正當成保證產品質量的最後一道關卡，成為一個BT（BestTester）就指日可待了！

軟件測試用例的認識誤區

　　軟件測試用例是為了有效發現軟件缺陷而編寫的包含測試目的、測試步驟、期望測試結果的特定集合。正確認識和設計軟件測試用例可以提高軟件測試的有效性，便於測試質量的度量，增強測試過程的可管理性。

　　在實際軟件項目測試過程中，由於對軟件測試用例的作用和設計方法的理解不同，測試人員（特別是剛從事軟件測試的新人）對軟件測試用例存在不少錯誤的認識，給實際軟件測試帶來了負面影響，本文對這些認識誤區進行列舉和剖析。

 

 

誤區之一：測試輸入數據設計方法等同於測試用例設計方法

　　現在一些測試書籍和文章中講到軟件測試用例的設計方法，經常有這樣的表述：測試用例的設計方法包括：等價類、邊界值、因果圖、錯誤推測法、場景設計法等。這種表述是很片面的，這些方法只是軟件功能測試用例設計中如何確定測試輸入數據的方法，而不是測試用例設計的全部內容。

　　這種認識的不良影響可能會使不少人認為測試用例設計就是如何確定測試的輸入數據，從而掩蓋了測試用例設計內容的豐富性和技術的複雜性。如果測試用例設計人員把這種認識拿來要求自己，則害了自己；拿來教人，則害了別人；拿來指導測試，則害了測試團隊。聽起來似乎是“小題大做”，但是絕不是“危言聳聽”。

　　無疑，對於軟件功能測試和性能測試，確定測試的輸入數據很重要，它決定了測試的有效性和測試的效率。但是，測試用例中輸入數據的確定方法只是測試用例設計方法的一個子集，除了確定測試輸入數據之外，測試用例的設計還包括如何根據測試需求、設計規格說明等文檔確定測試用例的設計策略、設計用例的表示方法和組織管理形式等問題。

　　在設計測試用例時，需要綜合考慮被測軟件的功能、特性、組成元素、開發階段（里程碑）、測試用例組織方法（是否採用測試用例的數據庫管理）等內容。具體到設計每個測試用例而言，可以根據被測模塊的最小目標，確定測試用例的測試目標；根據用戶使用環境確定測試環境；根據被測軟件的複雜程度和測試用例執行人員的技能確定測試用例的步驟；根據軟件需求文檔和設計規格說明確定期望的測試用例執行結果。

 

 

誤區之二：強調測試用例設計得越詳細越好

　　在確定測試用例設計目標時，一些項目管理人員強調測試用例“越詳細越好”。具體表現在兩個方面：盡可能設計足夠多的設計用例，測試用例的數量閱讀越好；測試用例盡可能包括測試執行的詳細步驟，達到“任何一個人都可以根據測試用例執行測試”，追求測試用例越詳細越好。

　　這種做法和觀點最大的危害就是耗費了很多的測試用例設計時間和資源，可能等到測試用例設計、評審完成后，留給實際執行測試的時間所剩無幾了。因為當前軟件公司的項目團隊在規劃測試階段，分配給測試的時間和人力資源是有限的，而軟件項目的成功要堅持“質量、時間、成本”的最佳平衡，沒有足夠多的測試執行時間，就無法發現更多的軟件缺陷，測試質量更無從談起了。

　　編寫測試用例的根本目的是有效地找出軟件可能存在的缺陷，為了達到這個目的，需要分析被測試軟件的特徵，運用有效的測試用例設計方法，盡量使用較少的測試用例，同時滿足合理的測試需求覆蓋，從而達到“少花時間多辦事”的效果。

　　測試用例中的測試步驟需要詳細到什麼程度，主要取決於測試用例的“最終用戶”（即執行這些測試用例的人員），以及測試用例執行人員的技能和產品熟悉程度。如果編寫測試用例的人員也是測試用例執行人員，或者測試用例的執行人員深刻了解被測軟件，測試用例就沒有必要太詳細。而如果是測試新人執行測試用例，或者軟件測試外包給獨立的第三方公司，那麼測試用例的執行步驟最好足夠詳細。

 

誤區之三：追求測試用例設計“一步到位”

　　現在軟件公司都意識到了測試用例設計的重要性了，但是一些人認為設計測試用例是一次性投入，測試用例設計一次就“萬事大吉”了，片面追求測試設計的“一步到位”。

這種認識造成的危害性使設計出的測試用例缺乏實用性，或者誤導測試用例執行人員，誤報很多不是軟件缺陷的“Bug”，這樣的測試用例在測試執行過程中“形同虛設”，難免淪為“垃圾文檔”的地步。

　　“唯一不變的是變化”。任何軟件項目的開發過程都處於不斷變化過程中，用戶可能對軟件的功能提出新需求，設計規格說明相應地更新，軟件代碼不斷細化。設計軟件測試用例與軟件開發設計并行進行，必須根據軟件設計的變化，對軟件測試用例進行內容的調整，數量的增減，增加一些針對軟件新增功能的測試用例，刪除一些不再適用的測試用例，修改那些模塊代碼更新了的測試用例。

　　軟件測試用例設計只是測試用例管理的一個過程，除此之外，還要對其進行評審、更新、維護，以便提高測試用例的“新鮮度”，保證“可用性”。因此，軟件測試用例也要堅持“與時俱進”的原則。

 

 

誤區之四：讓測試新人設計測試用例

　　在與測試同行交流的過程中，不少剛參加測試工作的測試新人經常詢問的一個問題是：“怎麼才能設計好測試用例？”。因為他（她）們以前從來沒有設計過測試用例，面對大型的被測試軟件感到“老虎吃天，無從下口”。

　　讓測試新人設計測試用例是一種高風險的測試組織方式，它帶來的不利後果是設計出的測試用例對軟件功能和特性的測試覆蓋性不高，編寫效率低，審查和修改時間長，可重用性差。

　　軟件測試用例設計是軟件測試的中高級技能，不是每個人（尤其是測試新人）都可以編寫的，測試用例編寫者不僅要掌握軟件測試的技術和流程，而且要對被測軟件的設計、功能規格說明、用戶試用場景以及程序/模塊的結構都有比較透徹的理解。

　　因此，實際測試過程中，通常安排經驗豐富的測試人員進行測試用例設計，測試新人可以從執行測試用例開始，隨着項目進度的不斷進展，測試人員的測試技術和對被測軟件的不斷熟悉，可以積累測試用例的設計經驗，編寫測試用例。

 

 

 

【精選推薦文章】

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

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

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

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

SpringBoot系列文章簡介

SpringBoot源碼閱讀輔助篇：

　　Spring IoC容器與應用上下文的設計與實現

SpringBoot啟動流程源碼分析：

1. SpringBoot啟動流程分析（一）：SpringApplication類初始化過程
2. SpringBoot啟動流程分析（二）：SpringApplication的run方法
3. SpringBoot啟動流程分析（三）：SpringApplication的run方法之prepareContext()方法
4. SpringBoot啟動流程分析（四）：IoC容器的初始化過程
5. SpringBoot啟動流程分析（五）：SpringBoot自動裝配原理實現
6. SpringBoot啟動流程分析（六）：IoC容器依賴注入

筆者註釋版Spring Framework與SpringBoot源碼git傳送門：請不要吝嗇小星星

1. spring-framework-5.0.8.RELEASE
2. SpringBoot-2.0.4.RELEASE

一、前言

　　前面我們對IoC容器的初始化過程進行了詳細的分析，這個初始化過程完成的主要工作是在IoC容器中建立BeanDefinition數據映射。在此過程中並沒有看到IoC容器對Bean依賴關係進行注入，接下來分析一下IoC容器是怎樣對Bean的依賴關係進行注入的。

　　前面在refresh()–>invokeBeanFactoryPostProcessors(beanFactory);方法中已經完成了IoC容器的初始化並已經載入了我們定義的Bean的信息（BeanDefinition），現在我們開始分析依賴注入的原理。首先需要說明的是依賴注入在用戶第一次向IoC容器索要Bean時觸發，當然也有例外，我們可以在BeanDefinition中中通過控制lazy-init屬性來讓容器完成對Bean的預實例化。這個預實例化實際上也是一個依賴注入的過程，但它是在初始化過程中完成的。

 

二、源碼分析

2.1、getBean()的過程

　　接着前面看refresh()方法，這已經是refresh()方法的第三篇博文了，別迷糊我們還沒走出refresh()方法。

 1 // AbstractApplicationContext類
 2 @Override
 3 public void refresh() throws BeansException, IllegalStateException {
 4     synchronized (this.startupShutdownMonitor) {
 5         ...
 6         try {
 7             ...
 8             // Instantiate all remaining (non-lazy-init) singletons.
 9             finishBeanFactoryInitialization(beanFactory);
10             ...
11         }
12         ...
13     }
14 }
15 // AbstractApplicationContext類
16 protected void finishBeanFactoryInitialization(ConfigurableListableBeanFactory beanFactory) {
17     ...
18     // Instantiate all remaining (non-lazy-init) singletons.
19     // 實例化所有剩餘的(non-lazy-init)單例。
20     beanFactory.preInstantiateSingletons();
21 }
22 // DefaultListableBeanFactory類
23 @Override
24 public void preInstantiateSingletons() throws BeansException {
25     ...
26     // Iterate over a copy to allow for init methods which in turn register new bean definitions.
27     // While this may not be part of the regular factory bootstrap, it does otherwise work fine.
28     List<String> beanNames = new ArrayList<>(this.beanDefinitionNames);
29     // Trigger initialization of all non-lazy singleton beans...
30     for (String beanName : beanNames) {
31         RootBeanDefinition bd = getMergedLocalBeanDefinition(beanName);
32         if (!bd.isAbstract() && bd.isSingleton() && !bd.isLazyInit()) {
33             if (isFactoryBean(beanName)) {
34                 Object bean = getBean(FACTORY_BEAN_PREFIX + beanName);
35                 if (bean instanceof FactoryBean) {
36                     final FactoryBean<?> factory = (FactoryBean<?>) bean;
37                     boolean isEagerInit;
38                     if (System.getSecurityManager() != null && factory instanceof SmartFactoryBean) {
39                         isEagerInit = AccessController.doPrivileged((PrivilegedAction<Boolean>)
40                                         ((SmartFactoryBean<?>) factory)::isEagerInit,
41                                 getAccessControlContext());
42                     } else {
43                         isEagerInit = (factory instanceof SmartFactoryBean &&
44                                 ((SmartFactoryBean<?>) factory).isEagerInit());
45                     }
46                     if (isEagerInit) {
47                         getBean(beanName);
48                     }
49                 }
50             } else {
51                 // 這裏就是觸發依賴注入的地方
52                 getBean(beanName);
53             }
54         }
55     }
56     ...
57 }

 　　跟蹤其調用棧，看到上面第52行的getBean(beanName);方法，我們再梳理一下getBean()方法，前面總結過該方法在IoC容器的頂層接口BeanFactory中定義，然後在IoC容器的具體產品DefaultListableBeanFactory類的基類AbstractBeanFactory實現了getBean()方法。接着看代碼。

 1 // AbstractBeanFactory類
 2 @Override
 3 public Object getBean(String name) throws BeansException {
 4     return doGetBean(name, null, null, false);
 5 }
 6 @Override
 7 public <T> T getBean(String name, @Nullable Class<T> requiredType) throws BeansException {
 8     return doGetBean(name, requiredType, null, false);
 9 }
10 @Override
11 public Object getBean(String name, Object... args) throws BeansException {
12     return doGetBean(name, null, args, false);
13 }
14 public <T> T getBean(String name, @Nullable Class<T> requiredType, @Nullable Object... args)
15         throws BeansException {
16     return doGetBean(name, requiredType, args, false);
17 }

　　從上面代碼可知大致可分為兩種獲取Bean的參數，一種是按名獲取，一種是按類獲取。但是最終都進入到了doGetBean()方法。

  1 // AbstractBeanFactory類
  2 protected <T> T doGetBean(final String name, @Nullable final Class<T> requiredType,
  3         @Nullable final Object[] args, boolean typeCheckOnly) throws BeansException {
  4 
  5     // bean獲取過程：先獲取bean名字
  6     // 會把帶有&前綴的去掉，或者去aliasMap中找這個是不是別名，最終確定bean的id是什麼
  7     final String beanName = transformedBeanName(name);
  8     Object bean;
  9 
 10     // 1.檢查緩存中或者實例工廠中是否有對應的實例
 11     // 因為在創建單例bean的時候會存在依賴注入的情況，而在創建依賴的時候為了避免循環依賴
 12     // Spring在創建bean的時候不會等bean創建完成就會將bean的ObjectFactory提早曝光
 13     // 也就是將ObjectFactory加入到緩存中，一旦下一個要創建的bean需要依賴上個bean則直接使用ObjectFactory
 14     // 2.spring 默認是單例的，如果能獲取到直接返回，提高效率。
 15     // Eagerly check singleton cache for manually registered singletons.
 16     Object sharedInstance = getSingleton(beanName);
 17     if (sharedInstance != null && args == null) {
 18         if (logger.isDebugEnabled()) {
 19             if (isSingletonCurrentlyInCreation(beanName)) {
 20                 logger.debug("Returning eagerly cached instance of singleton bean '" + beanName +
 21                         "' that is not fully initialized yet - a consequence of a circular reference");
 22             }
 23             else {
 24                 logger.debug("Returning cached instance of singleton bean '" + beanName + "'");
 25             }
 26         }
 27         // 用於檢測bean的正確性，同時如果獲取的是FactoryBean的話還需要調用getObject()方法獲取最終的那個bean實例
 28         bean = getObjectForBeanInstance(sharedInstance, name, beanName, null);
 29     }
 30 
 31     else {
 32         // Fail if we're already creating this bean instance:
 33         // We're assumably within a circular reference.
 34         if (isPrototypeCurrentlyInCreation(beanName)) {
 35             throw new BeanCurrentlyInCreationException(beanName);
 36         }
 37 
 38         // Check if bean definition exists in this factory.
 39         //這裏對IoC容器中的BeanDefinition是否存在進行檢查，檢查是否能在當前的BeanFactory中取得需要的Bean。
 40         // 如果當前的工廠中取不到，則到雙親BeanFactory中去取。如果當前的雙親工廠取不到，那就順着雙親BeanFactory
 41         // 鏈一直向上查找。
 42         BeanFactory parentBeanFactory = getParentBeanFactory();
 43         if (parentBeanFactory != null && !containsBeanDefinition(beanName)) {
 44             // Not found -> check parent.
 45             String nameToLookup = originalBeanName(name);
 46             if (parentBeanFactory instanceof AbstractBeanFactory) {
 47                 // 遞歸調用父bean的doGetBean查找
 48                 return ((AbstractBeanFactory) parentBeanFactory).doGetBean(
 49                         nameToLookup, requiredType, args, typeCheckOnly);
 50             }
 51             else if (args != null) {
 52                 // Delegation to parent with explicit args.
 53                 return (T) parentBeanFactory.getBean(nameToLookup, args);
 54             }
 55             else {
 56                 // No args -> delegate to standard getBean method.
 57                 return parentBeanFactory.getBean(nameToLookup, requiredType);
 58             }
 59         }
 60 
 61         if (!typeCheckOnly) {
 62             markBeanAsCreated(beanName);
 63         }
 64 
 65         try {
 66             //這裏根據Bean的名字取得BeanDefinition
 67             final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);
 68             checkMergedBeanDefinition(mbd, beanName, args);
 69 
 70             // Guarantee initialization of beans that the current bean depends on.
 71             //獲取當前Bean的所有依賴Bean，這裡會觸發getBean的遞歸調用。知道取到一個沒有任何依賴的Bean為止。
 72             String[] dependsOn = mbd.getDependsOn();
 73             if (dependsOn != null) {
 74                 for (String dep : dependsOn) {
 75                     if (isDependent(beanName, dep)) {
 76                         throw new BeanCreationException(mbd.getResourceDescription(), beanName,
 77                                 "Circular depends-on relationship between '" + beanName + "' and '" + dep + "'");
 78                     }
 79                     registerDependentBean(dep, beanName);
 80                     try {
 81                         getBean(dep);
 82                     }
 83                     catch (NoSuchBeanDefinitionException ex) {
 84                         throw new BeanCreationException(mbd.getResourceDescription(), beanName,
 85                                 "'" + beanName + "' depends on missing bean '" + dep + "'", ex);
 86                     }
 87                 }
 88             }
 89 
 90             // 這裏通過createBean方法創建singleton Bean的實例 這裏還有一個回調函數
 91             // Create bean instance.
 92             if (mbd.isSingleton()) {
 93                 sharedInstance = getSingleton(beanName, () -> {
 94                     try {
 95                         // 最後在getSingleton中又會調用這個方法
 96                         // TODO createBean的入口
 97                         return createBean(beanName, mbd, args);
 98                     }
 99                     catch (BeansException ex) {
100                         // Explicitly remove instance from singleton cache: It might have been put there
101                         // eagerly by the creation process, to allow for circular reference resolution.
102                         // Also remove any beans that received a temporary reference to the bean.
103                         destroySingleton(beanName);
104                         throw ex;
105                     }
106                 });
107                 bean = getObjectForBeanInstance(sharedInstance, name, beanName, mbd);
108             }
109             // 這裡是創建prototype bean的地方
110             else if (mbd.isPrototype()) {
111                 // It's a prototype -> create a new instance.
112                 Object prototypeInstance = null;
113                 try {
114                     beforePrototypeCreation(beanName);
115                     prototypeInstance = createBean(beanName, mbd, args);
116                 }
117                 finally {
118                     afterPrototypeCreation(beanName);
119                 }
120                 bean = getObjectForBeanInstance(prototypeInstance, name, beanName, mbd);
121             }
122 
123             else {
124                 String scopeName = mbd.getScope();
125                 final Scope scope = this.scopes.get(scopeName);
126                 if (scope == null) {
127                     throw new IllegalStateException("No Scope registered for scope name '" + scopeName + "'");
128                 }
129                 try {
130                     Object scopedInstance = scope.get(beanName, () -> {
131                         beforePrototypeCreation(beanName);
132                         try {
133                             return createBean(beanName, mbd, args);
134                         }
135                         finally {
136                             afterPrototypeCreation(beanName);
137                         }
138                     });
139                     bean = getObjectForBeanInstance(scopedInstance, name, beanName, mbd);
140                 }
141                 catch (IllegalStateException ex) {
142                     throw new BeanCreationException(beanName,
143                             "Scope '" + scopeName + "' is not active for the current thread; consider " +
144                             "defining a scoped proxy for this bean if you intend to refer to it from a singleton",
145                             ex);
146                 }
147             }
148         }
149         catch (BeansException ex) {
150             cleanupAfterBeanCreationFailure(beanName);
151             throw ex;
152         }
153     }
154 
155     // Check if required type matches the type of the actual bean instance.
156     //這裏對創建的Bean進行類型檢查，如果沒有問題，就返回這個新創建的Bean，這個Bean已經是包含了依賴關係的Bean
157     if (requiredType != null && !requiredType.isInstance(bean)) {
158         try {
159             T convertedBean = getTypeConverter().convertIfNecessary(bean, requiredType);
160             if (convertedBean == null) {
161                 throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
162             }
163             return convertedBean;
164         }
165         catch (TypeMismatchException ex) {
166             if (logger.isDebugEnabled()) {
167                 logger.debug("Failed to convert bean '" + name + "' to required type '" +
168                         ClassUtils.getQualifiedName(requiredType) + "'", ex);
169             }
170             throw new BeanNotOfRequiredTypeException(name, requiredType, bean.getClass());
171         }
172     }
173     return (T) bean;
174 }

　　這個就是依賴注入的入口了，依賴注入是在容器的BeanDefinition數據已經建立好的前提下進行的。“程序=數據+算法”，很經典的一句話，前面我們詳細介紹了BeanDefinition的註冊過程，BeanDefinition就是數據。如上面代碼所示，doGetBean()方法不涉及複雜的算法，但是這個過程也不是很簡單，因為我們都知道，對於IoC容器的使用，Spring提供了很多的配置參數，每一個配置參數實際上就代表了一個IoC容器的實現特徵，這些特徵很多都需要在依賴注入的過程或者對Bean進行生命周期管理的過程中完成。雖然我們可以簡單的將IoC容器描述成一個ConcurrentHashMap，ConcurrentHashMap只是它的數據結構而不是IoC容器的全部。

TIPS:
　　1，我在工程中簡單寫了一個controller和一個service，我們在後面debug看看依賴注入的過程是怎麼樣的，
也不知道我能不能說清楚。希望大家看到這一塊多debug一下，debug技巧如下圖所示，寫了debug的條件，
因為這邊到處都是遞歸和回調函數，再加上有很多Spring的Bean，但是我們只關心自己的Bean，
所以就寫了這樣的過濾條件：beanName.equals("webController")||beanName.equals("webService")
@RestController
public class WebController {
    @Autowired
    private WebService webService;

    @RequestMapping("/web")
    public String web(){
        return webService.hello();
    }
}

 

　　下面我們通過代碼看看獲取bean的過程。

　　OK，看代碼，Object sharedInstance = getSingleton(beanName);如註釋所說，首先回去找在容器中是不是已經存在該單例。具體在哪找我們在前面的文章中已經說得很清楚了。看一下getSingleton()方法

 1 // DefaultSingletonBeanRegistry類
 2 protected Object getSingleton(String beanName, boolean allowEarlyReference) {
 3     // 由於scope是singleton，所以先從緩存中取單例對象的實例，如果取到直接返回，沒有取到加載bean
 4     Object singletonObject = this.singletonObjects.get(beanName);
 5     // 當想要獲取的bean沒有被加載，並且也沒有正在被創建的時候，主動去加載bean
 6     if (singletonObject == null && isSingletonCurrentlyInCreation(beanName)) {
 7         // 鎖住單例緩存區加載bean
 8         synchronized (this.singletonObjects) {
 9             // singletonObjects ，earlySingletonObjects ，singletonFactories是一個單例實例的三種存在狀態
10             // 再去earlySingletonObjects中去找
11             singletonObject = this.earlySingletonObjects.get(beanName);
12             if (singletonObject == null && allowEarlyReference) {
13                 // 去singletonFactories中去找對象的實例
14                 ObjectFactory<?> singletonFactory = this.singletonFactories.get(beanName);
15                 if (singletonFactory != null) {
16                     singletonObject = singletonFactory.getObject();
17                     this.earlySingletonObjects.put(beanName, singletonObject);
18                     this.singletonFactories.remove(beanName);
19                 }
20             }
21         }
22     }
23     return singletonObject;
24 }

 

 　　在DefaultSingletonBeanRegistry類中的singletonObjects屬性就是存singleton bean的地方。

　　如果getSingleton()為 null繼續往下看，會在當前的BeanFactory中獲取BeanDefinition，也就是這行方法代碼：final RootBeanDefinition mbd = getMergedLocalBeanDefinition(beanName);在這行代碼拿到BeanDefinition后，首先判斷是不是singleton Bean，如果是的話，開始執行創建Bean，正是return createBean(beanName, mbd, args);這行代碼。如果是原型(Prototype)Bean我們就不分析了。原型bean每次執行getBean()都會創建一個實例。接下來我們看createBean()方法。

2.2、createBean()的過程

　　首先看一下create bean的過程

1，Bean實例的創建
2，為Bean實例設置屬性(屬性注入，其實就是依賴注入真正發生的地方)
3，調用Bean的初始化方法

　　前面說了getBean()是依賴注入的起點，之後會調用createBean()，下面通過createBean()代碼來了解這個過程。在這個過程中，Bean對象會根據BeanDefinition定義的要求生成。

 1 // AbstractAutowireCapableBeanFactory類
 2 @Override
 3 protected Object createBean(String beanName, RootBeanDefinition mbd, @Nullable Object[] args)
 4         throws BeanCreationException {
 5     ...
 6     try {
 7         // 驗證以及準備override的方法
 8         mbdToUse.prepareMethodOverrides();
 9     }
10     catch (BeanDefinitionValidationException ex) {
11         throw new BeanDefinitionStoreException(mbdToUse.getResourceDescription(),
12                 beanName, "Validation of method overrides failed", ex);
13     }
14     try {
15         // Give BeanPostProcessors a chance to return a proxy instead of the target bean instance.
16         // createBean之前調用BeanPostProcessor的postProcessBeforeInitialization和postProcessAfterInitialization方法
17         // 默認不做任何處理所以會返回null
18         // 但是如果我們重寫了這兩個方法，那麼bean的創建過程就結束了，這裏就為以後的annotation自動注入提供了鈎子
19         Object bean = resolveBeforeInstantiation(beanName, mbdToUse);
20         if (bean != null) {
21             return bean;
22         }
23     }catch (Throwable ex) {
24         throw new BeanCreationException(mbdToUse.getResourceDescription(), beanName,
25                 "BeanPostProcessor before instantiation of bean failed", ex);
26     }
27     try {
28         // 實際執行createBean的是doCreateBean()方法
29         Object beanInstance = doCreateBean(beanName, mbdToUse, args);
30         if (logger.isDebugEnabled()) {
31             logger.debug("Finished creating instance of bean '" + beanName + "'");
32         }
33         return beanInstance;
34     }
35     catch (BeanCreationException | ImplicitlyAppearedSingletonException ex) {
36         // A previously detected exception with proper bean creation context already,
37         // or illegal singleton state to be communicated up to DefaultSingletonBeanRegistry.
38         throw ex;
39     }
40     catch (Throwable ex) {
41         throw new BeanCreationException(
42                 mbdToUse.getResourceDescription(), beanName, "Unexpected exception during bean creation", ex);
43     }
44 }

 　　接着往下看doCreateBean()方法。

  1 // AbstractAutowireCapableBeanFactory類
  2 protected Object doCreateBean(final String beanName, final RootBeanDefinition mbd, final @Nullable Object[] args)
  3         throws BeanCreationException {
  4     // BeanWrapper是用來持有創建出來的Bean對象
  5     // Instantiate the bean.
  6     BeanWrapper instanceWrapper = null;
  7     // 如果是單例，先把緩存中的同名Bean清除
  8     if (mbd.isSingleton()) {
  9         instanceWrapper = this.factoryBeanInstanceCache.remove(beanName);
 10     }
 11     // 這裡是創建Bean的地方，由createBeanInstance完成。
 12     // TODO 完成Bean初始化過程的第一步：創建實例
 13     if (instanceWrapper == null) {
 14         instanceWrapper = createBeanInstance(beanName, mbd, args);
 15     }
 16     final Object bean = instanceWrapper.getWrappedInstance();
 17     Class<?> beanType = instanceWrapper.getWrappedClass();
 18     if (beanType != NullBean.class) {
 19         mbd.resolvedTargetType = beanType;
 20     }
 21 
 22     // Allow post-processors to modify the merged bean definition.
 23     synchronized (mbd.postProcessingLock) {
 24         if (!mbd.postProcessed) {
 25             try {
 26                 applyMergedBeanDefinitionPostProcessors(mbd, beanType, beanName);
 27             }
 28             catch (Throwable ex) {
 29                 throw new BeanCreationException(mbd.getResourceDescription(), beanName,
 30                         "Post-processing of merged bean definition failed", ex);
 31             }
 32             mbd.postProcessed = true;
 33         }
 34     }
 35 
 36     // Eagerly cache singletons to be able to resolve circular references
 37     // even when triggered by lifecycle interfaces like BeanFactoryAware.
 38     // 是否自動解決循環引用
 39     // 當bean條件為： 單例&&允許循環引用&&正在創建中這樣的話提早暴露一個ObjectFactory
 40     boolean earlySingletonExposure = (mbd.isSingleton() && this.allowCircularReferences &&
 41             isSingletonCurrentlyInCreation(beanName));
 42     if (earlySingletonExposure) {
 43         if (logger.isDebugEnabled()) {
 44             logger.debug("Eagerly caching bean '" + beanName +
 45                     "' to allow for resolving potential circular references");
 46         }
 47         // 把ObjectFactory放進singletonFactories中
 48         // 這裡在其他bean在創建的時候會先去singletonFactories中查找有沒有beanName到ObjectFactory的映射
 49         // 如果有ObjectFactory就調用它的getObject方法獲取實例
 50         // 但是在這裏就可以對一個bean進行保證，代理等等AOP就可以在getEarlyBeanReference這裏實現
 51         addSingletonFactory(beanName, () -> getEarlyBeanReference(beanName, mbd, bean));
 52     }
 53 
 54     // Initialize the bean instance.
 55     Object exposedObject = bean;
 56     try {
 57         // TODO 完成Bean初始化過程的第二步：為Bean的實例設置屬性
 58         // Bean依賴注入發生的地方
 59         // 對bean進行屬性填充，如果存在依賴於其他的bean的屬性，則會遞歸的調用初始化依賴的bean
 60         populateBean(beanName, mbd, instanceWrapper);
 61         // TODO 完成Bean初始化過程的第三步：調用Bean的初始化方法（init-method）
 62         // 調用初始化方法，比如init-method方法指定的方法
 63         exposedObject = initializeBean(beanName, exposedObject, mbd);
 64     }
 65     catch (Throwable ex) {
 66         if (ex instanceof BeanCreationException && beanName.equals(((BeanCreationException) ex).getBeanName())) {
 67             throw (BeanCreationException) ex;
 68         }
 69         else {
 70             throw new BeanCreationException(
 71                     mbd.getResourceDescription(), beanName, "Initialization of bean failed", ex);
 72         }
 73     }
 74 
 75     if (earlySingletonExposure) {
 76         Object earlySingletonReference = getSingleton(beanName, false);
 77         if (earlySingletonReference != null) {
 78             if (exposedObject == bean) {
 79                 exposedObject = earlySingletonReference;
 80             }
 81             else if (!this.allowRawInjectionDespiteWrapping && hasDependentBean(beanName)) {
 82                 String[] dependentBeans = getDependentBeans(beanName);
 83                 Set<String> actualDependentBeans = new LinkedHashSet<>(dependentBeans.length);
 84                 for (String dependentBean : dependentBeans) {
 85                     if (!removeSingletonIfCreatedForTypeCheckOnly(dependentBean)) {
 86                         actualDependentBeans.add(dependentBean);
 87                     }
 88                 }
 89                 if (!actualDependentBeans.isEmpty()) {
 90                     throw new BeanCurrentlyInCreationException(beanName,
 91                             "Bean with name '" + beanName + "' has been injected into other beans [" +
 92                             StringUtils.collectionToCommaDelimitedString(actualDependentBeans) +
 93                             "] in its raw version as part of a circular reference, but has eventually been " +
 94                             "wrapped. This means that said other beans do not use the final version of the " +
 95                             "bean. This is often the result of over-eager type matching - consider using " +
 96                             "'getBeanNamesOfType' with the 'allowEagerInit' flag turned off, for example.");
 97                 }
 98             }
 99         }
100     }
101 
102     // Register bean as disposable.
103     try {
104         // 註冊銷毀方法,比如：可以在配置bean的時候指定destory-method方法
105         registerDisposableBeanIfNecessary(beanName, bean, mbd);
106     }
107     catch (BeanDefinitionValidationException ex) {
108         throw new BeanCreationException(
109                 mbd.getResourceDescription(), beanName, "Invalid destruction signature", ex);
110     }
111 
112     return exposedObject;
113 }

　　結合上面的代碼，我們再來看一下創建Bean的三個步驟，是不是有點豁然開朗的感覺。別著急繼續往下看。

1，Bean實例的創建，instanceWrapper = createBeanInstance(beanName, mbd, args);
2，為Bean實例設置屬性，populateBean(beanName, mbd, instanceWrapper);
3，調用Bean的初始化方法，exposedObject = initializeBean(beanName, exposedObject, mbd);

 

2.2.1、createBeanInstance()：Bean實例的創建

　　看代碼

 1 // AbstractAutowireCapableBeanFactory類
 2 protected BeanWrapper createBeanInstance(String beanName, RootBeanDefinition mbd, @Nullable Object[] args) {
 3     // Make sure bean class is actually resolved at this point.
 4     // 確認需要創建的Bean的實例的類可以實例化
 5     Class<?> beanClass = resolveBeanClass(mbd, beanName);
 6 
 7     if (beanClass != null && !Modifier.isPublic(beanClass.getModifiers()) && !mbd.isNonPublicAccessAllowed()) {
 8         throw new BeanCreationException(mbd.getResourceDescription(), beanName,
 9                 "Bean class isn't public, and non-public access not allowed: " + beanClass.getName());
10     }
11 
12     Supplier<?> instanceSupplier = mbd.getInstanceSupplier();
13     if (instanceSupplier != null) {
14         return obtainFromSupplier(instanceSupplier, beanName);
15     }
16 
17     // 當有工廠方法的時候使用工廠方法初始化Bean，就是配置的時候指定FactoryMethod屬性，類似註解中的@Bean把方法的返回值作為Bean
18     if (mbd.getFactoryMethodName() != null)  {
19         return instantiateUsingFactoryMethod(beanName, mbd, args);
20     }
21 
22     // Shortcut when re-creating the same bean...
23     boolean resolved = false;
24     boolean autowireNecessary = false;
25     if (args == null) {
26         synchronized (mbd.constructorArgumentLock) {
27             if (mbd.resolvedConstructorOrFactoryMethod != null) {
28                 resolved = true;
29                 autowireNecessary = mbd.constructorArgumentsResolved;
30             }
31         }
32     }
33     if (resolved) {
34         if (autowireNecessary) {
35             // 如果有有參數的構造函數，構造函數自動注入
36             // 這裏spring會花費大量的精力去進行參數的匹配
37             return autowireConstructor(beanName, mbd, null, null);
38         }
39         else {
40             // 如果沒有有參構造函數，使用默認構造函數構造
41             return instantiateBean(beanName, mbd);
42         }
43     }
44 
45     // Need to determine the constructor...
46     // 使用構造函數進行實例化
47     Constructor<?>[] ctors = determineConstructorsFromBeanPostProcessors(beanClass, beanName);
48     if (ctors != null ||
49             mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_CONSTRUCTOR ||
50             mbd.hasConstructorArgumentValues() || !ObjectUtils.isEmpty(args))  {
51         return autowireConstructor(beanName, mbd, ctors, args);
52     }
53 
54     // No special handling: simply use no-arg constructor.
55     // 使用默認的構造函數對Bean進行實例化
56     return instantiateBean(beanName, mbd);
57 }

 

　　我們可以看到在instantiateBean()方法中生成了Bean所包含的Java對象，這個對象的生成有很多種不同的方式，可以通過工廠方法生成，也可以通過容器的autowire特性生成，這些生成方式都是由BeanDefinition決定的。對於上面我們的WebController和WebService兩個類是通過最後一行，使用默認的構造函數進行Bean的實例化。

　　接着看instantiateBean()方法。

 1 // AbstractAutowireCapableBeanFactory類
 2 protected BeanWrapper instantiateBean(final String beanName, final RootBeanDefinition mbd) {
 3     // 使用默認的實例化策略對Bean進行實例化，默認的實例化策略是CglibSubclassingInstantiationStrategy，
 4     // 也就是常說的CGLIB來對Bean進行實例化。PS：面試官常問的字節碼增強
 5     try {
 6         Object beanInstance;
 7         final BeanFactory parent = this;
 8         if (System.getSecurityManager() != null) {
 9             beanInstance = AccessController.doPrivileged((PrivilegedAction<Object>) () ->
10                     getInstantiationStrategy().instantiate(mbd, beanName, parent),
11                     getAccessControlContext());
12         }
13         else {
14             // getInstantiationStrategy()會返回CglibSubclassingInstantiationStrategy類的實例
15             beanInstance = getInstantiationStrategy().instantiate(mbd, beanName, parent);
16         }
17         BeanWrapper bw = new BeanWrapperImpl(beanInstance);
18         initBeanWrapper(bw);
19         return bw;
20     }
21     catch (Throwable ex) {
22         throw new BeanCreationException(
23                 mbd.getResourceDescription(), beanName, "Instantiation of bean failed", ex);
24     }
25 }

　　這裏使用CGLIB進行Bean的實例化。CGLIB是一個常用的字節碼生成器的類庫，其提供了一系列的API來提供生成和轉換Java字節碼的功能。在Spring AOP中同樣也是使用的CGLIB對Java的字節碼進行增強。在IoC容器中，使用SimpleInstantiationStrategy類。這個類是Spring用來生成Bean對象的默認類，它提供了兩種實例化Java對象的方法，一種是通過BeanUtils，它使用的是JVM的反射功能，一種是通過CGLIB來生成。

　　getInstantiationStrategy()方法獲取到CglibSubclassingInstantiationStrategy實例，instantiate()是CglibSubclassingInstantiationStrategy類的父類SimpleInstantiationStrategy實現的。

　　繼續看代碼

 1 // SimpleInstantiationStrategy類
 2 @Override
 3 public Object instantiate(RootBeanDefinition bd, @Nullable String beanName, BeanFactory owner) {
 4     // Don't override the class with CGLIB if no overrides.
 5     // 如果BeanFactory重寫了Bean內的方法，則使用CGLIB，否則使用BeanUtils
 6     if (!bd.hasMethodOverrides()) {
 7         // 如果bean沒有需要動態替換的方法就直接反射進行創建實例
 8         Constructor<?> constructorToUse;
 9         synchronized (bd.constructorArgumentLock) {
10             constructorToUse = (Constructor<?>) bd.resolvedConstructorOrFactoryMethod;
11             if (constructorToUse == null) {
12                 final Class<?> clazz = bd.getBeanClass();
13                 if (clazz.isInterface()) {
14                     throw new BeanInstantiationException(clazz, "Specified class is an interface");
15                 }
16                 try {
17                     if (System.getSecurityManager() != null) {
18                         constructorToUse = AccessController.doPrivileged(
19                                 (PrivilegedExceptionAction<Constructor<?>>) clazz::getDeclaredConstructor);
20                     } else {
21                         constructorToUse = clazz.getDeclaredConstructor();
22                     }
23                     bd.resolvedConstructorOrFactoryMethod = constructorToUse;
24                 } catch (Throwable ex) {
25                     throw new BeanInstantiationException(clazz, "No default constructor found", ex);
26                 }
27             }
28         }
29         // 通過BeanUtils進行實例化，這個BeanUtils的實例化通過Constructor類實例化Bean
30         // 在BeanUtils中可以看到具體的調用ctor.newInstances(args)
31         return BeanUtils.instantiateClass(constructorToUse);
32     } else {
33         // Must generate CGLIB subclass.
34         // TODO 使用CGLIB實例化對象
35         return instantiateWithMethodInjection(bd, beanName, owner);
36     }
37 }

　　在SpringBoot中我們一般採用@Autowire的方式進行依賴注入，很少採用像SpringMVC那種在xml中使用<lookup-method>或者<replaced-method>等標籤的方式對注入的屬性進行override，所以在上面的代碼中if(!bd.hasMethodOverrides())中的判斷為true，會採用BeanUtils的實例化方式。

 

2.2.2、populateBean();屬性設置（依賴注入）

　　看代碼

 1 protected void populateBean(String beanName, RootBeanDefinition mbd, @Nullable BeanWrapper bw) {
 2     if (bw == null) {
 3         if (mbd.hasPropertyValues()) {
 4             throw new BeanCreationException(
 5                     mbd.getResourceDescription(), beanName, "Cannot apply property values to null instance");
 6         }
 7         else {
 8             // Skip property population phase for null instance.
 9             return;
10         }
11     }
12     // Give any InstantiationAwareBeanPostProcessors the opportunity to modify the
13     // state of the bean before properties are set. This can be used, for example,
14     // to support styles of field injection.
15     boolean continueWithPropertyPopulation = true;
16     // 調用InstantiationAwareBeanPostProcessor  Bean的後置處理器，在Bean注入屬性前改變BeanDefinition的信息
17     if (!mbd.isSynthetic() && hasInstantiationAwareBeanPostProcessors()) {
18         for (BeanPostProcessor bp : getBeanPostProcessors()) {
19             if (bp instanceof InstantiationAwareBeanPostProcessor) {
20                 InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
21                 if (!ibp.postProcessAfterInstantiation(bw.getWrappedInstance(), beanName)) {
22                     continueWithPropertyPopulation = false;
23                     break;
24                 }
25             }
26         }
27     }
28     if (!continueWithPropertyPopulation) {
29         return;
30     }
31     // 這裏取得在BeanDefinition中設置的property值，這些property來自對BeanDefinition的解析
32     // 用於在配置文件中通過<property>配置的屬性並且显示在配置文件中配置了autowireMode屬性
33     PropertyValues pvs = (mbd.hasPropertyValues() ? mbd.getPropertyValues() : null);
34     if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME ||
35             mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
36         MutablePropertyValues newPvs = new MutablePropertyValues(pvs);
37 
38         // Add property values based on autowire by name if applicable.
39         // 這裏對autowire注入的處理，autowire by name
40         if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_NAME) {
41             autowireByName(beanName, mbd, bw, newPvs);
42         }
43 
44         // Add property values based on autowire by type if applicable.
45         // 這裏對autowire注入的處理， autowire by type
46         // private List<Test> tests;
47         if (mbd.getResolvedAutowireMode() == RootBeanDefinition.AUTOWIRE_BY_TYPE) {
48             autowireByType(beanName, mbd, bw, newPvs);
49         }
50 
51         pvs = newPvs;
52     }
53     boolean hasInstAwareBpps = hasInstantiationAwareBeanPostProcessors();
54     boolean needsDepCheck = (mbd.getDependencyCheck() != RootBeanDefinition.DEPENDENCY_CHECK_NONE);
55     if (hasInstAwareBpps || needsDepCheck) {
56         if (pvs == null) {
57             pvs = mbd.getPropertyValues();
58         }
59         PropertyDescriptor[] filteredPds = filterPropertyDescriptorsForDependencyCheck(bw, mbd.allowCaching);
60         if (hasInstAwareBpps) {
61             for (BeanPostProcessor bp : getBeanPostProcessors()) {
62                 if (bp instanceof InstantiationAwareBeanPostProcessor) {
63                     InstantiationAwareBeanPostProcessor ibp = (InstantiationAwareBeanPostProcessor) bp;
64                     // TODO @Autowire @Resource @Value @Inject 等註解的依賴注入過程
65                     pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);
66                     if (pvs == null) {
67                         return;
68                     }
69                 }
70             }
71         }
72         if (needsDepCheck) {
73             checkDependencies(beanName, mbd, filteredPds, pvs);
74         }
75     }
76     if (pvs != null) {
77         // 注入配置文件中<property>配置的屬性
78         applyPropertyValues(beanName, mbd, bw, pvs);
79     }
80 }

　　上面方法中的31-52行以及78行的applyPropertyValues()方法基本都是用於SpringMVC中採用xml配置Bean的方法。所以我們不做介紹了。看註釋知道幹嘛的就行了。我們主要看的是pvs = ibp.postProcessPropertyValues(pvs, filteredPds, bw.getWrappedInstance(), beanName);這行代碼，這行代碼是真正執行採用@Autowire @Resource @Value @Inject 等註解的依賴注入過程。

　　接着往下看

 1 // AutowiredAnnotationBeanPostProcessor類
 2 @Override
 3 public PropertyValues postProcessPropertyValues(
 4         PropertyValues pvs, PropertyDescriptor[] pds, Object bean, String beanName) throws BeanCreationException {
 5     // 遍歷，獲取@Autowire，@Resource，@Value，@Inject等具備註入功能的註解
 6     InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs);
 7     try {
 8         // 屬性注入
 9         metadata.inject(bean, beanName, pvs);
10     } catch (BeanCreationException ex) {
11         throw ex;
12     } catch (Throwable ex) {
13         throw new BeanCreationException(beanName, "Injection of autowired dependencies failed", ex);
14     }
15     return pvs;
16 }

　　AutowiredAnnotationBeanPostProcessor類實現了postProcessPropertyValues()方法。findAutowiringMetadata(beanName, bean.getClass(), pvs);方法會尋找在當前類中的被@Autowire，@Resource，@Value，@Inject等具備註入功能的註解的屬性。

　　debug看一下結果，如下圖所示，成功得到了@Autowire註解的屬性webService。

　　metadata.inject(bean, beanName, pvs);方法開始執行注入的邏輯。

 1 // AutowiredAnnotationBeanPostProcessor類
 2 @Override
 3 protected void inject(Object bean, @Nullable String beanName, @Nullable PropertyValues pvs) throws Throwable {
 4     // 需要注入的字段
 5     Field field = (Field) this.member;
 6     // 需要注入的屬性值
 7     Object value;
 8     if (this.cached) {
 9         value = resolvedCachedArgument(beanName, this.cachedFieldValue);
10     } else {
11         // @Autowired(required = false)，當在該註解中設置為false的時候，如果有直接注入，沒有跳過，不會報錯。
12         DependencyDescriptor desc = new DependencyDescriptor(field, this.required);
13         desc.setContainingClass(bean.getClass());
14         Set<String> autowiredBeanNames = new LinkedHashSet<>(1);
15         Assert.state(beanFactory != null, "No BeanFactory available");
16         TypeConverter typeConverter = beanFactory.getTypeConverter();
17         try {
18             // 通過BeanFactory 解決依賴關係
19             // 比如在webController中注入了webService，這個會去BeanFactory中去獲取webService，也就是getBean()的邏輯。
20             // 如果存在直接返回，不存在再執行createBean()邏輯。
21             // 如果在webService中依然依賴，依然會去遞歸。
22             // 這裡是一個複雜的遞歸邏輯。
23             value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter);
24         } catch (BeansException ex) {
25             throw new UnsatisfiedDependencyException(null, beanName, new InjectionPoint(field), ex);
26         }
27         synchronized (this) {
28             if (!this.cached) {
29                 if (value != null || this.required) {
30                     this.cachedFieldValue = desc;
31                     registerDependentBeans(beanName, autowiredBeanNames);
32                     if (autowiredBeanNames.size() == 1) {
33                         String autowiredBeanName = autowiredBeanNames.iterator().next();
34                         if (beanFactory.containsBean(autowiredBeanName) &&
35                                 beanFactory.isTypeMatch(autowiredBeanName, field.getType())) {
36                             this.cachedFieldValue = new ShortcutDependencyDescriptor(
37                                     desc, autowiredBeanName, field.getType());
38                         }
39                     }
40                 } else {
41                     this.cachedFieldValue = null;
42                 }
43                 this.cached = true;
44             }
45         }
46     }
47     if (value != null) {
48         ReflectionUtils.makeAccessible(field);
49         field.set(bean, value);
50     }
51 }

　　debug看一下field。如下圖所示正是我們的webService

　　看這行代碼：value = beanFactory.resolveDependency(desc, beanName, autowiredBeanNames, typeConverter);注意beanFactory依舊是我們熟悉的IoC容器的具體產品，也就是實現類DefaultListableBeanFactory。見到就說一遍，方便大家記住它，很重要。

　　在resolveDependency()方法中經過一頓操作，最終又會來到上面的getBean()方法。以上就是依賴注入的整個過程。注意看代碼中的註釋哦。

2.2.3、initializeBean()：調用Bean的初始化方法

　　設置Bean的初始化方法有兩種方法，一種是在xml或者@Bean指定init-method方法。另一種是讓bean實現InitializingBean接口重寫afterPropertiesSet()方法。

 1 // AbstractAutowireCapableBeanFactory類
 2 protected Object initializeBean(final String beanName, final Object bean, @Nullable RootBeanDefinition mbd) {
 3     if (System.getSecurityManager() != null) {
 4         AccessController.doPrivileged((PrivilegedAction<Object>) () -> {
 5             invokeAwareMethods(beanName, bean);
 6             return null;
 7         }, getAccessControlContext());
 8     }
 9     else {
10         //在調用Bean的初始化方法之前，調用一系列的aware接口實現，把相關的BeanName，BeanClassLoader，以及BeanFactory注入到Bean中去。
11         invokeAwareMethods(beanName, bean);
12     }
13 
14     Object wrappedBean = bean;
15     if (mbd == null || !mbd.isSynthetic()) {
16         // 這些都是鈎子方法，在反覆的調用，給Spring帶來了極大的可拓展性
17         // 初始化之前調用BeanPostProcessor
18         wrappedBean = applyBeanPostProcessorsBeforeInitialization(wrappedBean, beanName);
19     }
20 
21     try {
22         // 調用指定的init-method方法
23         invokeInitMethods(beanName, wrappedBean, mbd);
24     }
25     catch (Throwable ex) {
26         throw new BeanCreationException(
27                 (mbd != null ? mbd.getResourceDescription() : null),
28                 beanName, "Invocation of init method failed", ex);
29     }
30     if (mbd == null || !mbd.isSynthetic()) {
31         // 這些都是鈎子方法，在反覆的調用，給Spring帶來了極大的可拓展性
32         // 初始化之後調用BeanPostProcessor
33         wrappedBean = applyBeanPostProcessorsAfterInitialization(wrappedBean, beanName);
34     }
35 
36     return wrappedBean;
37 }

　　在調用Bean的初始化方法之前，調用一系列的aware接口實現，把相關的BeanName，BeanClassLoader，以及BeanFactory注入到Bean中去。接着會執行invokeInitMethods()方法。

 1 // AbstractAutowireCapableBeanFactory類
 2 protected void invokeInitMethods(String beanName, final Object bean, @Nullable RootBeanDefinition mbd)
 3         throws Throwable {
 4     // 除了使用init-method指定的初始化方法，還可以讓bean實現InitializingBean接口重寫afterPropertiesSet()方法
 5     boolean isInitializingBean = (bean instanceof InitializingBean);
 6     if (isInitializingBean && (mbd == null || !mbd.isExternallyManagedInitMethod("afterPropertiesSet"))) {
 7         if (logger.isDebugEnabled()) {
 8             logger.debug("Invoking afterPropertiesSet() on bean with name '" + beanName + "'");
 9         }
10         if (System.getSecurityManager() != null) {
11             try {
12                 AccessController.doPrivileged((PrivilegedExceptionAction<Object>) () -> {
13                     ((InitializingBean) bean).afterPropertiesSet();
14                     return null;
15                 }, getAccessControlContext());
16             }
17             catch (PrivilegedActionException pae) {
18                 throw pae.getException();
19             }
20         }
21         else {
22             // 執行afterPropertiesSet()方法進行初始化
23             ((InitializingBean) bean).afterPropertiesSet();
24         }
25     }
26 
27     // 先執行afterPropertiesSet()方法，再進行init-method
28     if (mbd != null && bean.getClass() != NullBean.class) {
29         String initMethodName = mbd.getInitMethodName();
30         if (StringUtils.hasLength(initMethodName) &&
31                 !(isInitializingBean && "afterPropertiesSet".equals(initMethodName)) &&
32                 !mbd.isExternallyManagedInitMethod(initMethodName)) {
33             invokeCustomInitMethod(beanName, bean, mbd);
34         }
35     }
36 }

　　可見該方法中首先判斷Bean是否配置了init-method方法，如果有，那麼通過invokeCustomInitMethod()方法來直接調用。其中在invokeCustomInitMethod()方法中是通過JDK的反射機製得到method對象，然後調用的init-method。最終完成Bean的初始化。

 

三、總結

　　SpringBoot啟動流程相關的博文到這裏就結束了，在前面的文章中，我們詳細介紹了IoC容器的設計與實現，並結合SpringBoot的啟動流程介紹了IoC容器的初始化過程，及IoC容器的依賴注入，及大家都很關心的SpringBoot是如何實現自動裝配的。關於SpringBoot的源碼分析基本就到這裏了，後面有計劃寫寫AOP的實現，以及很重要的Spring事務實現。

　　小半個月時間，熬了很多個凌晨，終於寫完了SpringBoot啟動流程系列博文。有辛苦更有收穫，我是從今年才開始寫博客的，以前每當想寫的時候，總想什麼時候能力足夠了，憋個大招再寫。回過頭來看之前的想法是十分錯誤的，寫博文不只是為了分享，最重要的是在寫博客的過程中能夠系統的梳理一下某一個技術棧的知識。好記性不如爛筆頭，看別人的博客很難get到自己想要的點，所以也是讓自己持續進步的一種方式。加油，各位。

 

 

　　原創不易，轉載請註明出處。

　　如有錯誤的地方還請留言指正。

【精選推薦文章】

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

想要讓你的商品在網路上成為最夯、最多人討論的話題?

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

不管是台北網頁設計公司、台中網頁設計公司，全省皆有專員為您服務

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