1. SpringBoot內置生命周期事件詳解 SpringBoot源碼(十)
SpringBoot中文注釋項目Github地址：扒派族
https://github.com/yuanmabiji/spring-boot-2.1.0.RELEASE
本篇接 SpringBoot事件監聽機制源碼分析(上) SpringBoot源碼(九)
溫故而知新，我們來簡單回顧一下上篇的內容，上一篇我們分析了 SpringBoot啟動時廣播生命周期事件的原理羨汪 ，現將關鍵步驟再濃縮總結下：
上篇文章的側重點是分析了SpringBoot啟動時廣播生命周期事件的原理，此篇文章我們再來詳細分析SpringBoot內置的7種生命周期事件的源碼。
分析SpringBoot的生命周期事件，我們先來看一張類結構圖：
由上圖可以看到事件類之間的關系：
EventObject 類是JDK的事件基類，可以說是所有Java事件類的基本，即所有的Java事件類都直接或間接繼承於該類，源碼如下：
可以看到 EventObject 類只有一個屬性 source ，這個屬性是用來記錄最初事件是發生在哪個類，舉個栗子，比如在SpringBoot啟動過程中會發射 ApplicationStartingEvent 事件，而這個事件最初是在 SpringApplication 類中發射的，因此 source 就是 SpringApplication 對象。
ApplicationEvent 繼承了DK的事件基類 EventObject 類，是Spring的事件基類，被所有Spring的具體事件類繼承，源碼如下：
可以看到 ApplicationEvent 有且僅有一個屬性 timestamp ，該屬性是用來記錄事件發生的時間。
SpringApplicationEvent 類繼承了Spring的事件基類 ApplicationEvent ，是所有SpringBoot內置生命周期事件的父類，源碼如下：
可以看到 SpringApplicationEvent 有且僅有一個屬性 args ，該屬性就是SpringBoot啟動時的命令行參數即標注 @SpringBootApplication 啟動類中 main 函數的參數。
接下來我們再來看一下 SpringBoot 內置生命周期事件即 SpringApplicationEvent 的具體子類們。
SpringBoot開始啟動時便會發布 ApplicationStartingEvent 事件，其發布時機在環境變數Environment或容器ApplicationContext創建前但在注冊 ApplicationListener 具體監聽器之後，標志標志 SpringApplication 開始啟動。
可以看到 事件多了一個 environment 屬性，我們不妨想一下，多了 environment 屬性的作用是啥？
答案就是 事件的 environment 屬性作用是利用事件發布訂閱機制，相應監聽器們可以從 事件中取出 environment 變數，然後我們可以為 environment 屬性增加屬性值或讀出 environment 變數中的值。
當SpringApplication已經開始啟動且環境變數 Environment 已經創建後，並且為環境變數 Environment 配置了命令行和 Servlet 等類型的環春弊境變數後，此時會發布 事件。
監聽 事件的第一個監聽器是 ConfigFileApplicationListener ，因為是 ConfigFileApplicationListener 監聽器還要為環境變數 Environment 增加 application.properties 配置文件中的環境變數；此後還有一些也是監聽 事件的其他監聽器監聽到此事件時，此時可以說環境變數 Environment 幾乎已經完全准備好了。
可以看到 事件多了個 類型的 context 屬性， context 屬性的作用同樣是為了相應監聽器可以拿到這個 context 屬性執行一些邏輯，具體作用將在 3.4.4 詳述。
事件在 ApplicationContext 容器創建後，且為 ApplicationContext 容器設置了 environment 變數和執行了 的初始化方法後但在bean定義載入前觸發，標志ApplicationContext已經初始化完畢。
同樣可以看到 ApplicationPreparedEvent 事件多了個 類型的 context 屬性，多了 context 屬性的作用是能讓監聽該事件的監聽器們能拿到 context 屬性，監聽器拿到 context 屬性一般有如下作用：
ApplicationPreparedEvent 事件在 ApplicationContext 容器已經完全准備好時但在容器刷新前觸發，在這個階段 bean 定義已經載入完畢還有 environment 已經准備好可以用了。
ApplicationStartedEvent 事件將在容器刷新後但 ApplicationRunner 和 CommandLineRunner 的 run 方法執行前觸發，標志 Spring 容器已經刷新，此時容器已經准備完畢了。
ApplicationReadyEvent 事件在調用完 ApplicationRunner 和 CommandLineRunner 的 run 方法後觸發，此時標志 SpringApplication 已經正在運行。
可以看到 ApplicationFailedEvent 事件除了多了一個 context 屬性外，還多了一個 Throwable 類型的 exception 屬性用來記錄SpringBoot啟動失敗時的異常。
ApplicationFailedEvent 事件在SpringBoot啟動失敗時觸發，標志SpringBoot啟動失敗。
此篇文章相對簡單，對SpringBoot內置的7種生命周期事件進行了詳細分析。我們還是引用上篇文章的一張圖來回顧一下這些生命周期事件及其用途：
由於有一些小夥伴們建議之前有些源碼分析文章太長，導致耐心不夠，看不下去，因此，之後的源碼分析文章如果太長的話，筆者將會考慮拆分為幾篇文章，這樣就比較短小了，比較容易看完，嘿嘿。
【源碼筆記】Github地址：
https://github.com/yuanmabiji/Java-SourceCode-Blogs
點贊搞起來，嘿嘿嘿！
公眾號【 源碼筆記 】專注於Java後端系列框架的源碼分析。
2. 如何正確地查看源代碼
一。先把源代碼安裝起來編譯起來，結合它的文檔和手冊，熟悉其功能和它的應用方式。如果遇到的是英文文檔，那麼首先恭喜你，如果硬著頭皮看下來，不僅能在國內開此系統或框架的先河，而且能讓你閱讀英文的水平大幅提升。
二。瀏覽源代碼的目錄結構，了解各個目錄的功能。從整體上觀察這個工程是有哪些模塊組成的，最好能畫一畫圖。
三。經過以上兩步後你對這份源代碼有了一個初步的了解了，現在開始分析它的源碼吧。這一步我們開始分析源代碼框架。例如入口方式是單入口還是多入口，頁面之間的調用規則，能根據規則找出某個功能用到的頁面。
四。熟悉源代碼的代碼寫作風格，例如縮進方式，排版格式，變數命名，函數命名等。
五。熟悉一下源代碼用到的資料庫和表，可以參考它的技術支持文檔。
六。經過以上幾步相信已經對源代碼有了更深刻的了解，不過這種了解還只是表面的，下來我們從7個方面具體的去分析它吧：
1.入口構造以及頁面調用方式的具體實現，如果閱讀時看到工具類和工具函數，盡量去熟悉一下。這一步的分析可以學習到源代碼的系統架構方式。
2.分析源代碼用到的工具類和工具函數，這樣可以學到很多程序編寫技巧。可以提升自己編程功力。
3.結合一些安全規則，研究這個源代碼是怎樣實現安全方面的設計的。這樣可以提高自己在安全方面的意識和功力。
4.如果有模板引擎的話，研究一下源代碼的模板引擎。大致從實現方式，效率，易用性等幾個方面去考慮。
5.研究系統的各個功能模塊，這樣既能學習編程技巧還能打開自己的編程思路，下次遇到類似的東東就心裡有譜了。
6.研究系統所用到設計模式，一樣的功能實現，用到的設計模式可能相差很多，對比我們之前所作的東東分析設計模式，是提升我們駕馭代碼的不二法門。
7.研究源代碼對訪問壓力，執行效率，系統效率，資料庫查詢的優化。
七。做筆記，把這個開源代碼實現的功能，實現方式、設計框架、模塊組織、以及代碼技巧等記錄下來。邊記錄邊總結整理，對學習的東西更容易消化吸收。
八。實踐是檢驗真理的唯一標准，修改一些比較簡單地功能，或者寫一些簡單的sample，並且調試出來，這樣才能做到更加理解代碼。同時框架性的源代碼里一般都有自帶的實例，修改使用這些實例，可以快速了解框架的使用。
3. Android源碼解析Window系列第（一）篇---Window的基本認識和Activity的載入流程
您可能聽說過View ,ViewManager,Window,PhoneWindow,WindowManager,WindowManagerService,可是你知道這幾個類是什麼關系，幹嘛用的。概括的來說，View是放在Window中的，Window是一個抽象類，它的具體實現是PhoneWindow，PhoneWindow還有個內部類DecorView，WindowManager是一個interface，繼承自ViewManager，它是外界訪問Window的入口，，提供了add/remove/updata的方法操作View，WindowManager與WindowManagerSerice是個跨進程的過程，WindowManagerService的職責是對系統中的所有窗口進行管理。如果您不太清楚，建議往下看，否則就不要看了。
Android系統的Window有很多種，大體上來說，Framework定義了三種窗口類型；
這就是Framework定義了三種窗口類型，這三種類型定義在WindowManager的內部類LayoutParams中，WindowManager講這三種類型 進行了細化，把每一種類型都用一個int常量來表示，這些常量代表窗口所在的層，WindowManagerService在進行窗口疊加的時候，會按照常量的大小分配不同的層，常量值越大，代表位置越靠上面， 所以我們可以猜想一下，應用程序Window的層值常量要小於子Window的層值常量，子Window的層值常量要小於系統Window的層值常量。 Window的層級關系如下所示。
上面說了Window分為三種，用Window的type區分，在搞清楚Window的創建之前，我們需要知道怎麼去描述一個Window，我們就把Window當做一個實體類，給我的感覺，它必須要下面幾個欄位。
實際上WindowManager.LayoutParams對Window有很詳細的定義。
提取幾個重要的參數
Window是一個是一個抽象的概念，千萬不要認為我們所看到的就是Window,我們平時所看到的是視圖，每一個Window都對應著一個View，View和Window通過ViewRootImpl來建立聯系。有了View，Window的存在意義在哪裡呢，因為View不能單獨存在，它必須依附著Window，所以有視圖的地方就有Window,比如Activity,一個Dialog,一個PopWindow,一個菜單，一個Toast等等。
通過上面我們知道視圖和Window的關系，那麼有一個問題，是先有視圖，還是先有Window。這個答案只有在源碼中找了。應用程序的入口類是ActivityThread，在ActivityThread中有performLaunchActivity來啟動Activity，這個performLaunchActivity方法內部會創建一個Activity。
如果activity不為null,就會調用attach,在attach方法中通過PolicyManager創建了Window對象，並且給Window設置了回調介面。
PolicyManager的實現類是Policy
這樣Window就創建出來了， 所以先有Window，後有視圖，視圖依賴Window存在 ，再說一說視圖（Activity）為Window設置的回調介面。
Activity實現了這個回調介面，當Window的狀態發生變化的時候，就會回調Activity中實現的這些介面，有些回調介面我們還是熟悉的，dispatchTouchEvent，onAttachedToWindow，onDetachedFromWindow等。
下面分析view是如何附屬到window上的，通過上面可以看到，在attach之後就要執行callActivityOnCreate，在onCreate中我們會調用setContentView方法。
getWindow獲取了Window對象，Window的具體實現類是PhoneWindow,所以要看PhoneWindow的setContentView方法。
這里涉及到一個mContentParent變數，他是一個DecorView的一部分，DecorView是PhoneWindow的一個內部類，我先介紹一下關於DecorView的知識。
DecorView是Activity的頂級VIew，DecorView繼承自FrameLayout,在DecorView中有上下兩個部分，上面是標題欄，下面是內容欄，我們通過PhoneWindow的setContentView所設置的布局文件是加到內容欄（mContentParent）裡面的，View層的事件都是先經過DecorView在傳遞給我們的View的。
OK在回到setContentView的源碼分析，我們可以得到Activity的Window創建需要三步。
- 1、 如果沒有DecorView，在installDecor中創建DecorView。
- 2、將View添加到decorview中的mContentParent中。
- 3、回調Activity的onContentChanged介面。
先看看第一步，installDecor的源碼
installDecor中調用了generateDecor，繼續看
直接給new一個DecorView，有了DecorView之後，就可以載入具體的布局文件到DecorView中了，具體的布局文件和系統和主題有關系。
在看第二步，將View添加到decorview中的mContentParent中。
直接將Activity視圖加到DecorView的mContentParent中，最後一步，回調Activity的onContentChanged介面。在Activity中尋找onContentChanged方法，它是個空實現，我們可以在子Activity中處理。
到此DecorView被創建完畢，我們一開始從Thread中的handleLaunchActivity方法開始分析，首先載入Activity的位元組碼文件，利用反射的方式創建一個Activity對象，調用Activity對象的attach方法，在attach方法中，創建系統需要的Window並為設置回調，這個回調定義在Window之中，由Activity實現，當Window的狀態發生變化的時候，就會回調Activity實現的這些回調方法。調用attach方法之後，Window被創建完成，這時候需要關聯我們的視圖，在handleLaunchActivity中的attach執行之後就要執行handleLaunchActivity中的callActivityOnCreate，在onCreate中我們會調用setContentView方法。通過setContentView，創建了Activity的頂級View---DecorView,DecorView的內容欄（mContentParent）用來顯示我們的布局。 這個是我們上面分析得到了一個大致流程，走到這里，這只是添加的過程，還要有一個顯示的過程，顯示的過程就要調用handleLaunchActivity中的handleResumeActivity方法了。最後會調用makeVisible方法。
這裡面首先拿到WindowManager對象，用tWindowManager 的父介面ViewManager接收，ViewManager可以
最後調用 mDecor.setVisibility(View.VISIBLE)設置mDecor可見。到此，我們終於明白一個Activity是怎麼顯示在我們的面前了。
參考鏈接：
http://blog.csdn.net/feiclear_up/article/details/49201357
4. UCOS----時鍾節拍源碼分析
時鍾節拍類似於人體心臟的跳動，人體依賴心臟的跳動將血液輸入身體各個部位，支撐生命活動。時鍾節拍的是操作系統的時基，操作系統依賴於時鍾節拍推動 CPU 去執行指令。
時鍾節拍是系統以固定的頻率產生中斷（時基中斷），並在中斷處理與時間相關的事件，推動所有任務向前運行。時鍾節拍需要依賴於硬體定時器，STM32 通常使用 systick 時鍾作為 MCU 的內核定時器。
根據系統時鍾的初始化，在系統計數達到後，產生時鍾中斷，並調用中斷處理函數 OS_CPU_SysTickHandler 。
在 OS_CPU_SysTickHandler 函數中調用了 UCOS 的時間片處理函數 OSTimeTick ，對系統的時間片進行處理。
在 OSTimeTick 函數中給時基任務、定時器任務都發送了信號量。這里先介紹時基任務。時基任務是在 OS 初始化函數 void OSInit (OS_ERR *p_err) 中創建。
本章闡述了時鍾節拍的工作原理，看似微小卻是整個 uC/OS 系統的命脈。時鍾節拍的運行依賴於 CPU 的定時器， STM32 專門為此量身定製了 SysTick 時鍾。每個時鍾節拍到來時，時基任務就會執行，節拍任務的重點是更新節拍任務列表。在節拍列表中，存放的均是與時間事件（如延時或超時）相關的任務。如果任務到期，則需要更新響應的任務狀態。
5. 如何分析網站源碼
分析網站源碼可以從以下同個方面
第一,網站採用的技術,是php還是asp,通常php好於asp
第二,網站布局結構是用的div/css還是tabel通常div布局更有利網站收錄
第三,網站的源碼是否支持二次開發,書寫是否規范.只要看代碼有沒有加密,有沒有注釋,易不易看懂
第四,網站源碼是否原創,是否有版權問題.如果你是要用它建站,這個還是要注意下了.免得吃官司
第五,源碼的安全性,可以用360網站網站在線安全檢測來檢查一下.
綜上所述就是分析網站的幾個點了,打了這么多字希望採納
6. 伺服器程序源代碼分析之二：php-fpm
php作為排名top2 互聯網開發工具，非常流行，可以參考：中國最大的25個網站採用技術選型方案
php這個名稱實際上有兩層含義
直接定義：
php-fpm從php5.3.3開始已經進入到php源代碼包，之前是作為patch存在的
很少人會去讀php本身源代碼，我6年前解決php內存泄露問題的時候做了些研究,最近再查看了一番，發現php的開發者很有誠意，這是一款非常出色的伺服器軟體，支持如下
在linux伺服器上，如果不設置 events.mechanism ,那麼默認就是採用epoll，所以
php-fpm的IO模型&並發處理能力和nginx是完全一致
nginx以性能卓越聞名，大部分程序員都認為php效率低下，看了源代碼，才知道這是傳奇啊
在高性能部署的時候，大家往往會針對性的優化nginx 。我自己之前部署php程序也犯了錯誤，8G內存的server，php-fpm的max children都會設置128+，現在看來太多了，參考nginx的部署:
php-fpm配置為 3倍 cpu core number就可以了
php-fpm穩定性比nginx稍差 這是因為php-fpm內置了一個php解析器,php-fpm進程就和php程序捆綁了，如果php腳本寫得不好，有死循環或者阻塞在某個遠端資源上，會拖累載入它的php-fpm進程
而nginx和後端應用伺服器之間通過網路連接，可以設置timeout，不容易堵死的
php-fpm的fastcgi是短連接 我原以為是長連接的，看了代碼才知道也是短連接，處理一個request就關閉掉
php-fpm介面採用fastcgi 非常遺憾，php-fpm和fastcgi完全綁定了，無法獨立使用 。只能部署在支持http-fcgi協議轉換程序背後(nginx）。其實可以考慮在php-fpm代碼包裡面引入http協議支持，這樣php-fpm可以獨立運行，讓nodejs無話可說
php-fpm等同於OpenResty OpenResty是一個國人開發的nginx模塊，就是在nginx引入lua解釋器. 實際上，它和php-fpm的唯一差別就是一個採用php語法，一個用lua，所以OpenResty要作為nginx增強包使用還可以，要選擇它作為一個主要編程工具，沒有任何必要
從架構上來說，php-fpm已經做到最好，超過大多數 python部署工具，我再也不黑它了
7. Netty源碼分析（七） PoolChunk
在分析源碼之前，我們先來了解一下Netty的內存管理機制。我們知道，jvm是自動管理內存的，這帶來了一些好處，在分配內存的時候可以方便管理，也帶來了一些問題。jvm每次分配內存的時候，都是先要去堆上申請內存空間進行分配，這就帶來了很大的性能上的開銷。當然，也可以使用堆外內存，Netty就用了堆外內存，但是內存的申請和釋放，依然需要性能的開銷。所以Netty實現了內存池來管理內存的申請和使用，提高了內存使用的效率。
PoolChunk就是Netty的內存管理的一種實現。Netty一次向系統申請16M的連續內存空間，這塊內存通過PoolChunk對象包裝，為了更細粒度的管理它，進一步的把這16M內存分成了2048個頁（pageSize=8k）。頁作為Netty內存管理的最基本的單位 ，所有的內存分配首先必須申請一塊空閑頁。Ps: 這里可能有一個疑問，如果申請1Byte的空間就分配一個頁是不是太浪費空間，在Netty中Page還會被細化用於專門處理小於4096Byte的空間申請 那麼這些Page需要通過某種數據結構跟演算法管理起來。
先來看看PoolChunk有哪些屬性
Netty採用完全二叉樹進行管理，樹中每個葉子節點表示一個Page，即樹高為12，中間節點表示頁節點的持有者。有了上面的數據結構，那麼頁的申請跟釋放就非常簡單了，只需要從根節點一路遍歷找到可用的節點即可。主要來看看PoolChunk是怎麼分配內存的。
Netty的內存按大小分為tiny,small,normal,而類型上可以分為PoolChunk,PoolSubpage，小於4096大小的內存就被分成PoolSubpage。Netty就是這樣實現了對內存的管理。
PoolChunk就分析到這里了。