你使用過哪些設計模式，挑幾個重點講一講實現
1單例設計模式（餓漢式和懶漢式）
單例設計模式（餓漢模式）
public class Singleton {
// 將自身實例化對象設置爲一個屬性，並用static、final修飾
private static final Singleton instance = new Singleton();
// 構造方法私有化
private Singleton() {}
// 靜態方法返回該實例
public static Singleton getInstance() {
return instance;
}
}
單例設計模式要確保類在內存中只有一個對象，該對象例必須自動的創建，並對外提供。
優點：在系統中內存中已存在一個對象，因此可以節約系統資源，對於一些需要頻繁的創建和銷燬的對象的單例模式
缺點是：沒有抽象層，因此在在擴展上很難。
單例設計模式的懶漢模式
public class Singleton {
// 將自身實例化對象設置爲一個屬性，並用static修飾
private static Singleton instance;
// 構造方法私有化
private Singleton() {}
// 靜態方法返回該實例
public static Singleton getInstance() {
if(instance == null) {
instance = new Singleton();
}
return instance;
}
}
開發中: 餓漢式（線程安全） 面試中：在懶漢式（可能會出先線程安全的問題）
懶加載（延遲加載）
線程安全問題：
1 是否有多線程環境
2 是否有數據共享
3 是否有多條語句的工享數據
單例的設計模式應用（餓漢式的設計）：
class RunTime {
//餓漢式的設計
private RunTime(){}
private static RunTime currentRuntime=new RunTime();
public static RunTime getCurrentRuntime(){
return currentRuntime;
}
}
2工廠模式（簡單工廠和抽象工廠）
簡單工廠模式（靜態工廠類）：是一個具體的負責的創建的一個類。
3觀察者模式
MQ工作原理是的設計就是的觀者模式的
4適配器的模式
5裝飾器設計模式
雙重校驗鎖如何實現？（這裏我回答漏了voliate關鍵字）
Mybatis底層如何綁定參數？#{}和${}有什麼區別？
作用:實現創建一個接口後把mapper.xml由mybatis生成接口的實現類,通過調用接口對象就可以獲取 mapper.xml 中編寫的 sql.
實現步驟：編寫接口按照下圖規則
單點登陸如何實現的？
登入
什麼是單點登錄？單點登錄全稱Single Sign On（以下簡稱SSO），是指在多系統應用羣中登錄一個系統，便可在其他所有系統中得到授權而無需再次登錄，包括單點登錄與單點註銷兩部分。
相比於單系統登錄，sso需要一個獨立的認證中心，只有認證中心能接受用戶的用戶名密碼等安全信息，其他系統不提供登錄入口，只接受認證中心的間接授權。間接授權通過令牌實現，sso認證中心驗證用戶的用戶名密碼沒問題，創建授權令牌，在接下來的跳轉過程中，授權令牌作爲參數發送給各個子系統，子系統拿到令牌，即得到了授權，可以藉此創建局部會話，局部會話登錄方式與單系統的登錄方式相同。這個過程，也就是單點登錄的原理。
下面對上圖簡要描述
- 用戶訪問系統1的受保護資源，系統1發現用戶未登錄，跳轉至sso認證中心，並將自己的地址作爲參數
- sso認證中心發現用戶未登錄，將用戶引導至登錄頁面
- 用戶輸入用戶名密碼提交登錄申請
- sso認證中心校驗用戶信息，創建用戶與sso認證中心之間的會話，稱爲全局會話，同時創建授權令牌
- sso認證中心帶着令牌跳轉會最初的請求地址（系統1）
- 系統1拿到令牌，去sso認證中心校驗令牌是否有效
- sso認證中心校驗令牌，返回有效，註冊系統1
- 系統1使用該令牌創建與用戶的會話，稱爲局部會話，返回受保護資源
- 用戶訪問系統2的受保護資源
- 系統2發現用戶未登錄，跳轉至sso認證中心，並將自己的地址作爲參數
- sso認證中心發現用戶已登錄，跳轉回系統2的地址，並附上令牌
- 系統2拿到令牌，去sso認證中心校驗令牌是否有效
- sso認證中心校驗令牌，返回有效，註冊系統2
- 系統2使用該令牌創建與用戶的局部會話，返回受保護資源
用戶登錄成功之後，會與sso認證中心及各個子系統建立會話，用戶與sso認證中心建立的會話稱爲全局會話，用戶與各個子系統建立的會話稱爲局部會話，局部會話建立之後，用戶訪問子系統受保護資源將不再通過sso認證中心，全局會話與局部會話有如下約束關係
- 局部會話存在，全局會話一定存在
- 全局會話存在，局部會話不一定存在
- 全局會話銷燬，局部會話必須銷燬
你可以通過博客園、百度、csdn、淘寶等網站的登錄過程加深對單點登錄的理解，注意觀察登錄過程中的跳轉url與參數。
註銷
單點登錄自然也要單點註銷，在一個子系統中註銷，所有子系統的會話都將被銷燬，用下面的圖來說明。
sso認證中心一直監聽全局會話的狀態，一旦全局會話銷燬，監聽器將通知所有註冊系統執行註銷操作。下面對上圖簡要說明
- 用戶向系統1發起註銷請求
- 系統1根據用戶與系統1建立的會話id拿到令牌，向sso認證中心發起註銷請求
- sso認證中心校驗令牌有效，銷燬全局會話，同時取出所有用此令牌註冊的系統地址
- sso認證中心向所有註冊系統發起註銷請求
- 各註冊系統接收sso認證中心的註銷請求，銷燬局部會話
- sso認證中心引導用戶至登錄頁面
springbean生命週期
實例化 Instantiation—》屬性賦值 Populate——》初始化 Initialization——》銷燬 Destruction
有幾種排序算法時間複雜度和空間複雜度分別是多少
1、http是否無狀態？如何有狀態？session和Cookies的區別。
http是一種的無狀態的。兩種用於保持HTTP狀態的技術就應運而生了，一個是 Cookie，而另一個則是 Session。
session：是一種將會話狀態保存在服務器端的技術。Cookie是一種在瀏覽器的技術。
Cookie ：Web 服務器保存在用戶瀏覽器（客戶端）上的小文本文件，它可以包含有關用戶的信息。無論何時用戶鏈接到服務器，Web 站點都可以訪問 Cookie信息 。
存儲位置不同：session 存儲在服務器端；cookie 存儲在瀏覽器端。
安全性不同：cookie 安全性一般，在瀏覽器存儲，可以被僞造和修改。
容量和個數限制：cookie 有容量限制，每個站點下的 cookie 也有個數限制。
存儲的多樣性：session 可以存儲在 Redis 中、數據庫中、應用程序中；而 cookie只能存儲在瀏覽器中。
session 的工作原理是客戶端登錄完成之後，服務器會創建對應的 session，session 創建完之後，會把 session 的 id 發送給客戶端，客戶端再存儲到瀏覽器中。這樣客戶端每次訪問服務器時，都會帶sessionid，服務器拿到 sessionid 之後，在內存找到與之對應的 session 這樣就可以正常工作了。session 只是依賴cookie存儲 sessionid，如果cookie 被禁用了，可以使用 url 中添加 sessionid 的方式保證 session 能正常使用。
2、http2.0特性？介紹一下http2.0。
1、完全採用二進制格式
2、多路複用：根據request的 id將request再歸屬到各自不同的服務端請求裏面，單個連接上同時進行多個業務單元數據的傳輸。
3、頭部壓縮
4、服務端推送
5、請求優先級
3、redis的數據結構。zset是什麼？如何實現的？
4、redis爲什麼快？內存+單線程。
5、如何設計分佈式鎖？利用redis的可重入鎖如何設計？
6、線程安全什麼意思？如何線程安全？
7、鎖的種類？公平鎖分公平鎖？redis分佈式鎖是否公平鎖？