簡述23種設計
- 抽象工廠模式（Abstract Factory）：提供一個創建一系列相關或相互依賴對象的接口，而無需指定它們具體的類。
- 適配器模式（Adapter）：將一個類的接口轉換成客戶希望的另外一個接口。適配器模式使得原本由於接口不兼容而不能一起工作的類可以一起工作。
- 橋樑模式（Bridge）：將抽象部分與他的實現部分分離，使他們都可以獨立的變化。
- 建造模式（Builder）：將一個複雜對象的構建與他的標表示分離，使同樣的構建過程可以創建不同的表示。
- 責任鏈模式（Chain of Responsibility）：爲解除請求的發送者和接收者之間耦合，而使多個對象都有幾乎處理這個請求。將這些對象連成一條鏈，並沿着這條鏈傳遞給請求，知道有一個對象處理他。
- 命令模式（Command）：將一個請求封裝爲一個對象，從而可用不同的請求對客戶進行參數化；對請求排列或記錄請求日誌，以及支持可取消的操作。【可以結合Active Object模式將每一個請求類用鏈表來維護，使請求統一在服務器端按順序執行，從而避免多線程問題。】
- 合成模式（Composite）：將對象組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和複合對象的使用具有一致性。
- 裝飾模式（Decorator）：動態地給一個對象添加一些額外的職責。就擴展功能而言，他能生成子類的方式更爲靈活。
- 門面模式（Facade）：爲子系統中的一組接口提供一個一致的界面，門面模式定義了一個高層接口，這個接口使得這一子系統更加容器使用。
- 工廠方法（Factory Mehtod）：定義一個用於創建對象的接口，讓子類決定將哪一個類實例化。Factory Method使一個類的實例化延遲到其子類。
- 享元模式（Flyweight）：運用共享技術以有效地支持大量細粒度的對象。
- 解釋器模式（Interpreter）：給定一個語言，定義他的語法的一種表示，並定義一個解釋器，該解釋器使用該表示解釋語言中的句子。
- 迭代子模式（Iterator）：提供一種方法順序訪問一個聚合對象中的各個元素，而又不需暴露該對象的內部表示。
- 調停者模式（Mediator）：用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式的內部表示。
- 備忘錄模式（Memento）：在不破壞封裝性的前提下，捕獲一個對象的內部狀態，並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到保存的狀態。
- 觀察者模式（Observer）：定義對象間的一種一對多的依賴關係，以便當一個對象的狀態發生改變時，所有依賴於他的對象都得到通知並自動刷新。
- 原始模型模式（Prototype）：用原型實例指定創建對象的種類，並且通過拷貝這個原型創建新的對象。
- 代理模式（Proxy）：爲其他對象提供一個代理以控制對這個對象的訪問。
- 單例模式（Singleton）：保證一個類僅有一個實例，並提供一個訪問他的全局訪問點。
- 狀態模式（State）：允許一個對象在其內部狀態改變時改變他的行爲。對象看起來似乎修改了他所屬的類。
- 策略模式（Strategy）：定義一系列的算法，把他們一個個封裝起來，並且使他們可相互替換。本模式使得算法的變化可獨立使用他的客戶。
- 模板模式（Template Mehtod）：定義一個操作中的算法的骨架，而將一些步驟延遲到子類中。模板方法使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
- 訪問者模式（Visitor）：表示一個作用於某對象結構中的各元素的做。該模式可以實現在不改變各元素的類的前提下定義作用於這些元素的新操作。
結合項目說一下設計模式
模板方法模式結合實例說的話，在提交訂單的抽象類，將提交訂單固定的方法實現例如，檢查購物車，支付方式,檢查用戶地址,生成發票等方法。
由於會根據訂單類型不同（例如web端訂單，ios端訂單，andorid端訂單等）而具體實現不同所以具體的提交訂單用抽象方法定義讓具體子類來實現提交訂單方法。
工廠模式在做電商系統時由於根據訂單類型創建的訂單實例不同。
所以運用了工廠模式，通過訂單類型獲取對應訂單實例。
策略模式之前做電商系統時候有規則引擎，通過不同的算法規則來執行不同的策略。
觀察者模式定義對象間一對多的依賴關係，當一個對象的狀態發生改變時，所有依賴於它的對象都得到通知自動更新
被觀察者擁有所有的觀察者實例，當被觀察者狀態變更時循環所有觀察者來通知變更。
常用語事件監聽中。
適配器模式是把一個類的接口變成客戶端所期待的另一種接口。分爲類適配器和對象適配器。
類適配器實現通過繼承部分實現的實現類來實現需要適配的接口。
對象適配器是通過實現類中包含部分實現的實現類實體來實現需要適配的接口。
當想適用積存的類，但接口不符合需求時可以選擇適配器模式。
單例模式spring容器就是一個典型的單例模式，實現的話就是定義static final 變量指向實例，並且私有化構造函數，
提供public方法來提供實例，確保該類只有一個實例。
gc的算法瞭解嗎
gc的基本算法有引用計數，複製，編輯-清掃，編輯-壓縮，分代等。
引用計數: 通過爲每一個對象添加一個計數器，通過計數器記錄該對象的活躍引用數量。
若計數器爲0就說明這個對象沒有被任何變量引用，gc就可以進行垃圾收集。
複製：是把內存空間劃分爲2個相等的區域，每次只使用一個區域。垃圾回收時，遍歷當前使用區域，把正在使用的對象複製到另外一個區域。
編輯-清掃：第一階段遍歷所有的引用，將有活的對象進行標記，第二階段對堆進行遍歷，把未標記的對象進行清除。但是需要暫停整個應用、並且會產生內存碎片。
標記-壓縮：第一階段標記活的對象，第二階段把未標記的對象壓縮並按順序放入堆中的某一塊中。
分代：基於對象生命週期分析得出的垃圾回收算法，把對象分爲年輕代、年老代、持久代，對不同生命週期使用不同的算法進行回收。
spring核心容器原理
Spring內部最核心的是IOC容器。就是具有依賴注入功能的容器。由容器根據配置文件去創建實例並創建各個實例之間的依賴關係。
由Spring容器初始化、裝配及管理的對象稱爲Bean。代表接口爲BeanFactory。提供了IOC容器的最基本功能。
而ApplicationContext繼承BeanFactory，增加了更多企業級功能的支持。
由於ioc的支持企業級普遍採用面向接口的開發模式。
順便說一下spring的AOP面向切面編程，其實是通過動態代理來截取消息的方式，對消息進行裝飾，取代原有對象的行爲的執行。
一般用於權限，緩存，日誌處理，事務，同步等場所應用。
JVM內存管理機制
程序計數器是用來指示執行哪條指令的。多線程是由CPU切換來執行的。所以在切換線程後爲了恢復在切換之前的線程執行爲止，所以每個線程都需要有自己獨立的程序計數器。
虛擬機 棧是java方法執行的內存模型。棧中存儲的是棧幀，每個棧幀對應被調用的方法，在棧幀中包括局部變量表、操作數棧、指向當前方法所屬的類的運行時常量池的引用、方法返回地址等。當線程執行方法時會隨之創建一個對應的棧幀，並將簡歷的棧幀壓棧，當方法執行完畢後將棧幀出棧。
局部變量表是用來存儲方法中的局部變量。對於基本數據類型的變量，則直接存儲值，對於引用類型的變量，則存儲指向對象的引用。
操作數棧的作用是程序中的所以計算過程都是藉助於操作數棧來完成的。
指向運行時常量池的引用，由於方法執行的過程中有可能需要用到類中的常量，所以必須要有一個引用指向運行時常量。
方法返回地址，作用是當一個方法執行完畢後，要返回之前調用它的地方，因此在棧幀中必須保存一個方法返回地址。
由於每個線程正在執行的方法可能不同，因此每個線程都會有獨立的虛擬機棧。
本地方法棧與虛擬機棧的作用和原理相似。區別在於服務對象。虛擬機棧是服務於java方法，本地方法棧服務於本地方法。
堆是用來存儲對象本身，以及數組等。資源是線程共享的，虛擬機棧中的引用指向堆中的具體實例，JVM中只有一個堆。
方法區也是線程共享的區域，存儲了每個類的信息(比如類的名稱、方法信息、字段信息等)、靜態變量、常量以及編譯器編譯後的代碼。
Java 線程池的作用
爲了解決一個服務器接受到大量短小線程的請求時避免產生很多創建和銷燬線程動作，減少服務器在創建和銷燬線程上花費的時間和消耗的系統資源。
賦：歡迎廣大java程序猿將自身經歷的面試題留言，博主會更新到文章中，謝謝支持~