1.JVM中加載類的時機具體舉例？以及雙親委派加載的機制是什么？

（1）JVM中加載類的時機具體舉例：

1）使用new關(guān)鍵字實例化對象，讀取或設(shè)置一個雷的靜態(tài)字段以及調(diào)用一個類的靜態(tài)方法的時候
2）使用java.lang.reflect包的方法對類進(jìn)行反射調(diào)用時，如果此類沒有初始化，則要觸發(fā)其初始化
3）當(dāng)初始化一個類是，發(fā)現(xiàn)其父類還沒有進(jìn)行初始化，則需要先觸發(fā)其父類的初始化
4）當(dāng)虛擬機啟動是，用戶需要指定一個要運行的主類，虛擬機會先初始化這個主類

（2）雙親委派加載的機制：

當(dāng)一個類收到了類加載請求，它首先不會嘗試自己去加載這個類，而是把這個請求委派給父類完成，每一個層次類加載器都是如此，因此，所有的加載請求都應(yīng)該傳送到啟動類加載其中，只有當(dāng)父類加載器反饋自己無法完成這個請求的時候，子類加載才會嘗試自己去加載。

2. Http協(xié)議和Https協(xié)議的區(qū)別是什么？

1）https協(xié)議需要到ca申請證書，一般免費證書較少，因而需要一定費用。
2）http是超文本傳輸協(xié)議，信息是明文傳輸，https則是具有安全性的ssl加密傳輸協(xié)議。
3）http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
4）http的連接很簡單，是無狀態(tài)的；HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全。

3. http協(xié)議中的Get請求和Post請求的區(qū)別是什么？

1） GET請求的數(shù)據(jù)是放在HTTP包頭中的，也就是URL之后，通常是像下面這樣定義格式的，（而Post是把提交的數(shù)據(jù)放在HTTP正文中的）。
login.action?name=hyddd&password=idontknow&verify=%E4%BD%E5%A5%BD
a，以 ？來分隔URL和數(shù)據(jù)；
b，以& 來分隔參數(shù)；
c，如果數(shù)據(jù)是英文或數(shù)字，原樣發(fā)送；
d，如果數(shù)據(jù)是中文或其它字符，則進(jìn)行BASE64編碼。?
2）GET提交的數(shù)據(jù)比較少，最多1024B，因為GET數(shù)據(jù)是附在URL之后的，而URL則會受到不同環(huán)境的限制的，比如說IE對其限制為2K+35，而POST可以傳送更多的數(shù)據(jù)（理論上是沒有限制的，但一般也會受不同的環(huán)境，如瀏覽器、操作系統(tǒng)、服務(wù)器處理能力等限制，IIS4可支持80KB，IIS5可支持100KB）。
3）Post的安全性要比Get高，因為Get時，參數(shù)數(shù)據(jù)是明文傳輸?shù)?，而且使用GET的話，還可能造成Cross-site request forgery攻擊。而POST數(shù)據(jù)則可以加密的，但GET的速度可能會快些。
所以綜上幾點，總結(jié)成下表：

4. TCP/IP協(xié)議中三次握手機制具體是什么？窗口滑動機制的作用和基本機制是什么？

Tcp/Ip協(xié)議的三次握手機制圖：

具體解釋如下：

第一次握手：客戶端向服務(wù)器端發(fā)送連接請求包SYN（syn=j），等待服務(wù)器回應(yīng)；
第二次握手：服務(wù)器端收到客戶端連接請求包SYN（syn=j）后，將客戶端的請求包SYN（syn=j）放入到自己的未連接隊列，此時服務(wù)器需要發(fā)送兩個包給客戶端；

（1）向客戶端發(fā)送確認(rèn)自己收到其連接請求的確認(rèn)包ACK（ack=j+1），向客戶端表明已知道了其連接請求
（2）向客戶端發(fā)送連接詢問請求包SYN（syn=k），詢問客戶端是否已經(jīng)準(zhǔn)備好建立連接，進(jìn)行數(shù)據(jù)通信；

第三次握手：客戶端收到服務(wù)器的ACK（ack=j+1）和SYN（syn=k）包后，知道了服務(wù)器同意建立連接，此時需要發(fā)送連接已建立的消息給服務(wù)器；
向服務(wù)器發(fā)送連接建立的確認(rèn)包ACK（ack=k+1），回應(yīng)服務(wù)器的SYN（syn=k）告訴服務(wù)器，我們之間已經(jīng)建立了連接，可以進(jìn)行數(shù)據(jù)通信。
ACK（ack=k+1）包發(fā)送完畢，服務(wù)器收到后，此時服務(wù)器與客戶端進(jìn)入ESTABLISHED狀態(tài)，開始進(jìn)行數(shù)據(jù)傳送。

窗口滑動機制的作用：

TCP協(xié)議作為一個可靠的面向流的傳輸協(xié)議，其可靠性和流量控制由滑動窗口協(xié)議保證，而擁塞控制則由控制窗口結(jié)合一系列的控制算法實現(xiàn)。

具體介紹：

窗口滑動就是說一次傳輸幾個數(shù)據(jù)。對所有數(shù)據(jù)幀按順序賦予編號，發(fā)送方在發(fā)送過程中始終保持著一個發(fā)送窗口，只有落在發(fā)送窗口內(nèi)的幀才允許被發(fā)送；同時接收方也維持著一個接收窗口，只有落在接收窗口內(nèi)的幀才允許接收。這樣通過調(diào)整發(fā)送方窗口和接收方窗口的大小可以實現(xiàn)流量控制。

5. Dubbo的優(yōu)點是什么？Dubbo對分布式事務(wù)是如何處理的？

Dubbo的優(yōu)點：

1）Dubbo具有調(diào)度、發(fā)現(xiàn)、監(jiān)控、治理等功能，支持相當(dāng)豐富的服務(wù)治理能力
2）集群容錯
當(dāng)服務(wù)調(diào)用失敗時，根據(jù)我們的業(yè)務(wù)不同，可以使用不同的策略來應(yīng)對這種失敗。
3）負(fù)載均衡
當(dāng)同一個服務(wù)有多個提供者在提供服務(wù)時， 客戶端如何正確的選擇提供者實現(xiàn)負(fù)載均衡dubbo也給我們提供了幾種方案
4）多協(xié)議
dubbo提供了多種協(xié)議給用戶選擇， 如Dubbo協(xié)議、Hessian協(xié)議、HTTP協(xié)議、RMI協(xié)議、WebService協(xié)議、Thrift協(xié)議、Memcached協(xié)議、Redis協(xié)議。

Dubbo對分布式事務(wù)的處理：

分布式事務(wù)暫不支持。用戶可以自己根據(jù)實際情況來實現(xiàn)分布式事務(wù)，比如：

1）結(jié)合RocketMQ消息中間件實現(xiàn)的可靠消息最終一致性
2）TCC補償性事務(wù)解決方案
3）最大努力通知型方案

6. Mysql數(shù)據(jù)庫的左連接、右連接、全連接？

左連接、右連接、全連接整體上屬于外連接的范疇。具體來講如下：

1）左連接：left join
左向外聯(lián)接的結(jié)果集包括 left join子句中指定的左表的所有行，而不僅僅是聯(lián)接列所匹配的行。如果左表的某行在右表中沒有匹配行，則在相關(guān)聯(lián)的結(jié)果集行中右表的所有選擇列表列均為空值。

左連接sql舉例：
select A.*,B.* from A left join B on A.id=B.infoid

2）右連接：right join
右向外聯(lián)接是左向外聯(lián)接的反向聯(lián)接。將返回右表的所有行。如果右表的某行在左表中沒有匹配行，則將為左表返回空值。

右連接sql舉例：
select A.*,B.* from A right join B on A.id=B.infoid

3）全連接：full join
完整外部聯(lián)接返回左表和右表中的所有行。當(dāng)某行在另一個表中沒有匹配行時，則另一個表的選擇列表列包含空值。如果表之間有匹配行，則整個結(jié)果集行包含基表的數(shù)據(jù)值。

全連接sql舉例：
select A.*,B.* from A full join B on A.id=B.infoid

7. 數(shù)據(jù)庫的悲觀鎖、樂觀鎖的機制和使用場景是什么??
悲觀鎖：
悲觀鎖的特點是先獲取鎖，再進(jìn)行業(yè)務(wù)操作，即“悲觀”的認(rèn)為獲取鎖是非常有可能失敗的，因此要先確保獲取鎖成功再進(jìn)行業(yè)務(wù)操作。

悲觀鎖的使用場景：
并發(fā)量不大且不允許臟讀，可以使用悲觀鎖解決并發(fā)問題

樂觀鎖：
樂觀鎖是先進(jìn)行業(yè)務(wù)操作，不到萬不得已不去拿鎖。即“樂觀”的認(rèn)為拿鎖多半是會成功的，因此在進(jìn)行完業(yè)務(wù)操作需要實際更新數(shù)據(jù)的最后一步再去拿一下鎖。

樂觀鎖的使用場景：
1）樂觀鎖在不發(fā)生取鎖失敗的情況下開銷比悲觀鎖小，但是一旦發(fā)生失敗回滾開銷則比較大，因此適合用在取鎖失敗概率比較小的場景，可以提升系統(tǒng)并發(fā)性能
2）樂觀鎖還適用于一些比較特殊的場景，例如在業(yè)務(wù)操作過程中無法和數(shù)據(jù)庫保持連接等悲觀鎖無法適用的地方

8. Zookeeper的典型應(yīng)用場景是什么？

1）命名服務(wù)(Naming Service)
2）數(shù)據(jù)發(fā)布與訂閱（配置中心）
3）分布式通知/協(xié)調(diào)
4）集群管理與Master選舉
5）分布式鎖
6）分布式隊列

---