框架篇
Spring
BeanFactory 和 ApplicationContext 有什麼區別
BeanFactory 可以理解爲含有bean集合的工廠類。BeanFactory 包含了種bean的定義，以便在接收到客戶端請求時將對應的bean實例化。
BeanFactory還能在實例化對象的時生成協作類之間的關係。此舉將bean自身與bean客戶端的配置中解放出來。BeanFactory還包含了bean生命週期的控制，調用客戶端的初始化方法（initialization methods）和銷燬方法（destruction methods）。
從表面上看，application context如同bean factory一樣具有bean定義、bean關聯關係的設置，根據請求分發bean的功能。但application context在此基礎上還提供了其他的功能。
提供了支持國際化的文本消息
統一的資源文件讀取方式
已在監聽器中註冊的bean的事件
摘抄自： http://www.importnew.com/15851.htmlSpring Bean 的生命週期
Spring Bean的生命週期簡單易懂。在一個bean實例被初始化時，需要執行一系列的初始化操作以達到可用的狀態。同樣的，當一個bean不在被調用時需要進行相關的析構操作，並從bean容器中移除。
Spring bean factory 負責管理在spring容器中被創建的bean的生命週期。Bean的生命週期由兩組回調（call back）方法組成。
初始化之後調用的回調方法。
銷燬之前調用的回調方法。
Spring框架提供了以下四種方式來管理bean的生命週期事件：
InitializingBean和DisposableBean回調接口
針對特殊行爲的其他Aware接口
Bean配置文件中的Custom init()方法和destroy()方法
@PostConstruct和@PreDestroy註解方式
摘抄自： http://www.importnew.com/15851.htmlSpring IOC 如何實現
Spring中的 org.springframework.beans 包和 org.springframework.context包構成了Spring框架IoC容器的基礎。
BeanFactory 接口提供了一個先進的配置機制，使得任何類型的對象的配置成爲可能。ApplicationContex接口對BeanFactory（是一個子接口）進行了擴展，在BeanFactory的基礎上添加了其他功能，比如與Spring的AOP更容易集成，也提供了處理message resource的機制（用於國際化）、事件傳播以及應用層的特別配置，比如針對Web應用的WebApplicationContext。
org.springframework.beans.factory.BeanFactory 是Spring IoC容器的具體實現，用來包裝和管理前面提到的各種bean。BeanFactory接口是Spring IoC 容器的核心接口。說說 Spring AOP
面向切面編程，在我們的應用中，經常需要做一些事情，但是這些事情與核心業務無關，比如，要記錄所有update方法的執行時間時間，操作人等等信息，記錄到日誌，
通過spring的AOP技術，就可以在不修改update的代碼的情況下完成該需求。Spring AOP 實現原理
Spring AOP中的動態代理主要有兩種方式，JDK動態代理和CGLIB動態代理。JDK動態代理通過反射來接收被代理的類，並且要求被代理的類必須實現一個接口。JDK動態代理的核心是InvocationHandler接口和Proxy類。
如果目標類沒有實現接口，那麼Spring AOP會選擇使用CGLIB來動態代理目標類。CGLIB（Code Generation Library），是一個代碼生成的類庫，可以在運行時動態的生成某個類的子類，注意，CGLIB是通過繼承的方式做的動態代理，因此如果某個類被標記爲final，那麼它是無法使用CGLIB做動態代理的。動態代理（cglib 與 JDK）
JDK 動態代理類和委託類需要都實現同一個接口。也就是說只有實現了某個接口的類可以使用Java動態代理機制。但是，事實上使用中並不是遇到的所有類都會給你實現一個接口。因此，對於沒有實現接口的類，就不能使用該機制。而CGLIB則可以實現對類的動態代理。
摘抄自： http://www.importnew.com/22015.htmlSpring 事務實現方式
1、編碼方式
所謂編程式事務指的是通過編碼方式實現事務，即類似於JDBC編程實現事務管理。
2、聲明式事務管理方式
聲明式事務管理又有兩種實現方式：基於xml配置文件的方式；另一個實在業務方法上進行@Transaction註解，將事務規則應用到業務邏輯中Spring 事務底層原理
a、劃分處理單元——IOC
由於spring解決的問題是對單個數據庫進行局部事務處理的，具體的實現首相用spring中的IOC劃分了事務處理單元。並且將對事務的各種配置放到了ioc容器中（設置事務管理器，設置事務的傳播特性及隔離機制）。
b、AOP攔截需要進行事務處理的類
Spring事務處理模塊是通過AOP功能來實現聲明式事務處理的，具體操作（比如事務實行的配置和讀取，事務對象的抽象），用TransactionProxyFactoryBean接口來使用AOP功能，生成proxy代理對象，通過TransactionInterceptor完成對代理方法的攔截，將事務處理的功能編織到攔截的方法中。讀取ioc容器事務配置屬性，轉化爲spring事務處理需要的內部數據結構（TransactionAttributeSourceAdvisor），轉化爲TransactionAttribute表示的數據對象。
c、對事物處理實現（事務的生成、提交、回滾、掛起）
spring委託給具體的事務處理器實現。實現了一個抽象和適配。適配的具體事務處理器：DataSource數據源支持、hibernate數據源事務處理支持、JDO數據源事務處理支持，JPA、JTA數據源事務處理支持。這些支持都是通過設計PlatformTransactionManager、AbstractPlatforTransaction一系列事務處理的支持。 爲常用數據源支持提供了一系列的TransactionManager。
d、結合
PlatformTransactionManager實現了TransactionInterception接口，讓其與TransactionProxyFactoryBean結合起來，形成一個Spring聲明式事務處理的設計體系。如何自定義註解實現功能
創建自定義註解和創建一個接口相似，但是註解的interface關鍵字需要以@符號開頭。
註解方法不能帶有參數；
註解方法返回值類型限定爲：基本類型、String、Enums、Annotation或者是這些類型的數組；
註解方法可以有默認值；
註解本身能夠包含元註解，元註解被用來註解其它註解。
摘抄自：http://www.importnew.com/20286.htmlSpring MVC 運行流程
1.spring mvc將所有的請求都提交給DispatcherServlet,它會委託應用系統的其他模塊負責對請求 進行真正的處理工作。
2.DispatcherServlet查詢一個或多個HandlerMapping,找到處理請求的Controller.
3.DispatcherServlet請請求提交到目標Controller
4.Controller進行業務邏輯處理後，會返回一個ModelAndView
5.Dispathcher查詢一個或多個ViewResolver視圖解析器,找到ModelAndView對象指定的視圖對象
6.視圖對象負責渲染返回給客戶端。
摘抄自：http://blog.csdn.net/liangzi_lucky/article/details/52459378Spring MVC 啓動流程
在 web.xml 文件中給 Spring MVC 的 Servlet 配置了 load-on-startup,所以程序啓動的
時候會初始化 Spring MVC，在 HttpServletBean 中將配置的 contextConfigLocation
屬性設置到 Servlet 中，然後在 FrameworkServlet 中創建了 WebApplicationContext,
DispatcherServlet 根據 contextConfigLocation 配置的 classpath 下的 xml 文件初始化了
Spring MVC 總的組件。
摘自： 《SpringMVC 源代碼分析與實踐》Spring 的單例實現原理
Spring 對 Bean 實例的創建是採用單例註冊表的方式進行實現的，而這個註冊表的緩存是 ConcurrentHashMap 對象。
摘抄自：http://blog.720ui.com/2017/design_pattern_singleton_reg/Spring 框架中用到了哪些設計模式
代理模式—在AOP和remoting中被用的比較多。
單例模式—在spring配置文件中定義的bean默認爲單例模式。
模板方法—用來解決代碼重複的問題。比如. RestTemplate, JmsTemplate, JpaTemplate。
前端控制器—Spring提供了DispatcherServlet來對請求進行分發。
視圖幫助(View Helper )—Spring提供了一系列的JSP標籤，高效宏來輔助將分散的代碼整合在視圖裏。
依賴注入—貫穿於BeanFactory / ApplicationContext接口的核心理念。
工廠模式—BeanFactory用來創建對象的實例。
摘抄自： http://www.importnew.com/15851.html#design_patterns_used_in_springSpring 其他產品（Srping Boot、Spring Cloud、Spring Secuirity、Spring Data、Spring AMQP 等）
Netty
爲什麼選擇 Netty
1) API使用簡單，開發門檻低；
2) 功能強大，預置了多種編解碼功能，支持多種主流協議；
3) 定製能力強，可以通過 ChannelHandler 對通信框架進行靈活的擴展；
4) 性能高，通過與其它業界主流的NIO框架對比，Netty的綜合性能最優；
5) 成熟、穩定，Netty修復了已經發現的所有JDK NIO BUG，業務開發人員不需要再爲NIO的BUG而煩惱；
6) 社區活躍，版本迭代週期短，發現的BUG可以被及時修復，同時，更多的新功能會被加入；
7) 經歷了大規模的商業應用考驗，質量已經得到驗證。在互聯網、大數據、網絡遊戲、企業應用、電信軟件等衆多行業得到成功商用，證明了它可以完全滿足不同行業的商業應用。
正是因爲這些優點，Netty逐漸成爲Java NIO編程的首選框架。
摘抄自：http://ifeve.com/netty-2-6/說說業務中，Netty 的使用場景
構建高性能、低時延的各種Java中間件，例如MQ、分佈式服務框架、ESB消息總線等，Netty主要作爲基礎通信框架提供高性能、低時延的通信服務；
公有或者私有協議棧的基礎通信框架，例如可以基於Netty構建異步、高性能的WebSocket協議棧；
各領域應用，例如大數據、遊戲等，Netty作爲高性能的通信框架用於內部各模塊的數據分發、傳輸和彙總等，實現模塊之間高性能通信。
摘抄自：http://www.voidcn.com/article/p-xydqhgxk-uk.html原生的 NIO 在 JDK 1.7 版本存在 epoll bug
它會導致Selector空輪詢，最終導致CPU 100%。官方聲稱在JDK 1.6版本的update18修復了該問題，但是直到JDK 1.7版本該問題仍舊存在，只不過該BUG發生概率降低了一些而已，它並沒有得到根本性解決。
摘抄自： http://blog.csdn.net/broadview2006/article/details/46041995什麼是TCP 粘包/拆包
1、要發送的數據大於TCP發送緩衝區剩餘空間大小，將會發生拆包。
2、待發送數據大於MSS（最大報文長度），TCP在傳輸前將進行拆包。
3、要發送的數據小於TCP發送緩衝區的大小，TCP將多次寫入緩衝區的數據一次發送出去，將會發生粘包。
4、接收數據端的應用層沒有及時讀取接收緩衝區中的數據，將發生粘包。
摘抄自：https://blog.insanecoder.top/tcp-packet-splice-and-split-issue/TCP粘包/拆包的解決辦法
1、發送端給每個數據包添加包首部，首部中應該至少包含數據包的長度，這樣接收端在接收到數據後，通過讀取包首部的長度字段，便知道每一個數據包的實際長度了。
2、發送端將每個數據包封裝爲固定長度（不夠的可以通過補0填充），這樣接收端每次從接收緩衝區中讀取固定長度的數據就自然而然的把每個數據包拆分開來。
3、可以在數據包之間設置邊界，如添加特殊符號，這樣，接收端通過這個邊界就可以將不同的數據包拆分開。
摘抄自：https://blog.insanecoder.top/tcp-packet-splice-and-split-issue/Netty 線程模型
首先，Netty使用EventLoop來處理連接上的讀寫事件，而一個連接上的所有請求都保證在一個EventLoop中被處理，一個EventLoop中只有一個Thread，所以也就實現了一個連接上的所有事件只會在一個線程中被執行。一個EventLoopGroup包含多個EventLoop，可以把一個EventLoop當做是Reactor線程模型中的一個線程，而一個EventLoopGroup類似於一個ExecutorService
作者：一字馬胡
鏈接：https://www.jianshu.com/p/128ddc36e713
來源：簡書
著作權歸作者所有。商業轉載請聯繫作者獲得授權，非商業轉載請註明出處。說說 Netty 的零拷貝
“零拷貝”是指計算機操作的過程中，CPU不需要爲數據在內存之間的拷貝消耗資源。而它通常是指計算機在網絡上發送文件時，不需要將文件內容拷貝到用戶空間（User Space）而直接在內核空間（Kernel Space）中傳輸到網絡的方式。
Netty 內部執行流程
- Netty的接收和發送ByteBuffer採用DIRECT BUFFERS，使用堆外直接內存進行Socket讀寫，不需要進行字節緩衝區的二次拷貝。如果使用傳統的堆內存（HEAP BUFFERS）進行Socket讀寫，JVM會將堆內存Buffer拷貝一份到直接內存中，然後才寫入Socket中。相比於堆外直接內存，消息在發送過程中多了一次緩衝區的內存拷貝。
- Netty提供了組合Buffer對象，可以聚合多個ByteBuffer對象，用戶可以像操作一個Buffer那樣方便的對組合Buffer進行操作，避免了傳統通過內存拷貝的方式將幾個小Buffer合併成一個大的Buffer。
- Netty的文件傳輸採用了transferTo方法，它可以直接將文件緩衝區的數據發送到目標Channel，避免了傳統通過循環write方式導致的內存拷貝問題。
摘抄自：http://blog.onlycatch.com/post/Netty%E4%B8%AD%E7%9A%84%E9%9B%B6%E6%8B%B7%E8%B4%9D
Netty 重連實現
1.心跳機制檢測連接存活
2.啓動時連接重試
3.運行中連接斷開時重試
摘抄自：http://www.spring4all.com/article/889
【轉載自：】http://www.spring4all.com/article/951