1. JVM中加載類的時機具體舉例？以及雙親委派加載的機制是什么？
（1）JVM中加載類的時機具體舉例：
1）使用new關鍵字實例化對象，讀取或設置一個雷的靜態字段以及調用一個類的靜態方法的時候
2）使用java.lang.reflect包的方法對類進行反射調用時，如果此類沒有初始化，則要觸發其初始化
3）當初始化一個類是，發現其父類還沒有進行初始化，則需要先觸發其父類的初始化
4）當虛擬機啟動是，用戶需要指定一個要運行的主類，虛擬機會先初始化這個主類
（2）雙親委派加載的機制：
當一個類收到了類加載請求，它首先不會嘗試自己去加載這個類，而是把這個請求委派給父類完成，每一個層次類加載器都是如此，因此，所有的加載請求都應該傳送到啟動類加載其中，只有當父類加載器反饋自己無法完成這個請求的時候，子類加載才會嘗試自己去加載。
2. Http協議和Https協議的區別是什么？
1）https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2）http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3）http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4）http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
3. http協議中的Get請求和Post請求的區別是什么？
1）https協議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2）http是超文本傳輸協議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協議。
3）http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4）http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。
4. TCP/IP協議中三次握手機制具體是什么？窗口滑動機制的作用和基本機制是什么？
Tcp/Ip協議的三次握手機制圖：
具體解釋如下：
第一次握手：客戶端向服務器端發送連接請求包SYN（syn=j），等待服務器回應；
第二次握手：服務器端收到客戶端連接請求包SYN（syn=j）后，將客戶端的請求包SYN（syn=j）放入到自己的未連接隊列，此時服務器需要發送兩個包給客戶端；
（1）向客戶端發送確認自己收到其連接請求的確認包ACK（ack=j+1），向客戶端表明已知道了其連接請求
（2）向客戶端發送連接詢問請求包SYN（syn=k），詢問客戶端是否已經準備好建立連接，進行數據通信；
第三次握手：客戶端收到服務器的ACK（ack=j+1）和SYN（syn=k）包后，知道了服務器同意建立連接，此時需要發送連接已建立的消息給服務器；
向服務器發送連接建立的確認包ACK（ack=k+1），回應服務器的SYN（syn=k）告訴服務器，我們之間已經建立了連接，可以進行數據通信。
ACK（ack=k+1）包發送完畢，服務器收到后，此時服務器與客戶端進入ESTABLISHED狀態，開始進行數據傳送。
窗口滑動機制的作用：
TCP協議作為一個可靠的面向流的傳輸協議，其可靠性和流量控制由滑動窗口協議保證，而擁塞控制則由控制窗口結合一系列的控制算法實現。
具體介紹：
窗口滑動就是說一次傳輸幾個數據。對所有數據幀按順序賦予編號，發送方在發送過程中始終保持著一個發送窗口，只有落在發送窗口內的幀才允許被發送；同時接收方也維持著一個接收窗口，只有落在接收窗口內的幀才允許接收。這樣通過調整發送方窗口和接收方窗口的大小可以實現流量控制。
5. Dubbo的優點是什么？Dubbo對分布式事務是如何處理的？
Dubbo的優點：
1）Dubbo具有調度、發現、監控、治理等功能，支持相當豐富的服務治理能力
2）集群容錯
當服務調用失敗時，根據我們的業務不同，可以使用不同的策略來應對這種失敗。
3）負載均衡
當同一個服務有多個提供者在提供服務時， 客戶端如何正確的選擇提供者實現負載均衡dubbo也給我們提供了幾種方案
4）多協議
dubbo提供了多種協議給用戶選擇， 如Dubbo協議、Hessian協議、HTTP協議、RMI協議、WebService協議、Thrift協議、Memcached協議、Redis協議。
Dubbo對分布式事務的處理：
分布式事務暫不支持。用戶可以自己根據實際情況來實現分布式事務，比如：
1）結合RocketMQ消息中間件實現的可靠消息最終一致性
2）TCC補償性事務解決方案
3）最大努力通知型方案
6. Mysql數據庫的左連接、右連接、全連接？
左連接、右連接、全連接整體上屬于外連接的范疇。具體來講如下：
1）左連接：left join
左向外聯接的結果集包括 left join子句中指定的左表的所有行，而不僅僅是聯接列所匹配的行。如果左表的某行在右表中沒有匹配行，則在相關聯的結果集行中右表的所有選擇列表列均為空值。
左連接sql舉例：
select A.*,B.* from A left join B on A.id=B.infoid
2）右連接：right join
右向外聯接是左向外聯接的反向聯接。將返回右表的所有行。如果右表的某行在左表中沒有匹配行，則將為左表返回空值。
右連接sql舉例：
select A.*,B.* from A right join B on A.id=B.infoid
3）全連接： full join
完整外部聯接返回左表和右表中的所有行。當某行在另一個表中沒有匹配行時，則另一個表的選擇列表列包含空值。如果表之間有匹配行，則整個結果集行包含基表的數據值。
全連接sql舉例：
select A.*,B.* from A full join B on A.id=B.infoid
7. 數據庫的悲觀鎖、樂觀鎖的機制和使用場景是什么?
悲觀鎖：
悲觀鎖的特點是先獲取鎖，再進行業務操作，即“悲觀”的認為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進行業務操作。
悲觀鎖的使用場景：
并發量不大且不允許臟讀，可以使用悲觀鎖解決并發問題
樂觀鎖：
樂觀鎖是先進行業務操作，不到萬不得已不去拿鎖。即“樂觀”的認為拿鎖多半是會成功的，因此在進行完業務操作需要實際更新數據的最后一步再去拿一下鎖。
樂觀鎖的使用場景：
1）樂觀鎖在不發生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統并發性能
2）樂觀鎖還適用于一些比較特殊的場景，例如在業務操作過程中無法和數據庫保持連接等悲觀鎖無法適用的地方
8. Zookeeper的典型應用場景是什么？
1）命名服務(Naming Service)
2）數據發布與訂閱（配置中心）
3）分布式通知/協調
4）集群管理與Master選舉
5）分布式鎖
6）分布式隊列
