高級面試題很是有用

時間 2019-11-12

原文原文鏈接

1，抽象類和接口的區別：
回答完概念後，我舉了適配器和裝飾器模式例子。適配器是把一個對象的接口轉換供另外一個接口調用，好比io讀寫的字符流經過適配器調用字節流對象來完成。
裝飾器模式是接口不變，把一個抽象父類的功能加強，好比文件io流就是實現了io流抽象對象，調用文件讀寫的io優化，加強了io功能。
最後我舉了本身項目中作C語言作USB轉串口的適配器模式。
2，講講單例模式：
回答完概念後，我講了餓漢和懶漢單例的實現，spring的默認單例運行。而後羅列一堆開源項目使用的單例+線程池。
最後講了本身項目中使用的單例。還講了適用範圍的，此處單例僅適用於程序內部，系統中程序只容許啓動一個實例的單例實現。html

數據庫鏈接池的設計通常也是採用單例模式，由於數據庫鏈接是一種數據庫資源。數據庫軟件系統中使用數據庫鏈接池，主要是節省打開或者關閉數據庫鏈接所引發的效率損耗，這種效率上的損耗仍是很是昂貴的，由於何用單例模式來維護，就能夠大大下降這種損耗。java

7. 多線程的線程池的設計通常也是採用單例模式，這是因爲線程池要方便對池中的線程進行控制。node

計數器通常也是單例的. mysql

3，講講string在內存的存儲：
答完string和通常值類型如int、double的不一樣，存儲在JVM的堆上，在棧上保存對象的引用。而後快速介紹jvm的GC算法。
最後講了在代碼中如何避免內存泄露。
4，cookie和session的優缺點：有用
回答完標準答案後，我講了一些本身項目中session共享的實現，快速畫簡要建構圖，而後簡單說了一下nginx反向代理配置tomcat集羣，tomcat裏配置session由某個開源插件來實現，session的產生由redis服務器來完成。
面試官恰好也研究過，問我單點登陸怎麼解決，我session共享關鍵問題解決後，只須要加臺用戶中心服務器便可。
實際上單點登陸我並無徹底實現，但這堆應付面試是無傷大雅的。真要實現單點登陸環境，相信給一週時間也能作出demo。
這時發現一個細節，面試官手裏的紙上寫了一些我說過的技術點，在設計模式和內存管理後面又加了一個單點登陸。linux

2、進階問題
5，講講多線程
我直接把《多線程編程核心》書裏的知識點快速介紹一遍，而後說了一下多線程實現生產者-消費者的僞代碼。
講了MQ消息隊列的點對點模式相似實現，引伸出了MQ消息隊列的發佈訂閱模式。這回有點表現過頭了，說到一些公平鎖和線程調度方面時，面試官有點發愣，我趕忙停下來等面試官問。
果真面試官可能有些不快地說，多線程你只是理論看得多，實際項目沒有使用過吧？我趕忙說很差意思，我說到本身擅長領域就忘記了環境(固然我確實也沒有遊戲編程那種多線程經驗)。
面試官態度變好了，我便拿那個專利項目舉例，說多線程除了異步等待耗時操做外，也能夠用在純計算耗CPU的場景，有幾個CPU核心開幾個線程把CPU全佔滿，以加快計算。
多線程被順利加入清單。
6，前面提到了MQ消息隊列，那麼你對分佈式有什麼經驗？
我坦言分佈式只是最近我在學習的，畫了個簡圖，簡單講了下dubbo、zookeper、activiedMQ、redis、FastDFS組成的分佈式架構。
分佈式有所瞭解這個技能又被加入清單。
7，講講你項目架構中的性能優化
狀態愈來愈好，性能優化我準備多時早就飢渴難耐了，這裏的綱要按照架構設計思惟導圖來說。
分前臺，後臺，數據庫優化三大方面來展開。
最後結合了我寫代碼的規範標準，本身總結的不比大公司人多力量大,做爲單打獨鬥的野生程序員能作到這個地步也差很少了.
8，咱們數據安全性很高，講講你的安全設計
我講了下本身登錄體系使用過的技術，密碼MD5，RSA加密用戶輸入數據，AES解密數據庫鏈接等。
中規中矩吧。
9，講講springMVC原理，及如何注入的
非基礎方面可能問不出什麼了，因而搞面試官冷不丁拋出一個基礎問題。個人思路一時沒法從系統架構的狀態上切換過來，想了10秒也想不起。
在面試官引導下，我說了經過包掃描來注入。面試官說很正常，他也常常忘記一些基本的東西。
10，final,finally,finalize的區別?
基礎關鍵字，若是這個答錯應該是會被扣分的（其中finalize方法是在垃圾收集器刪除對象以前調用的）。
固然基礎知識我怎麼可能忘記，順便發說了一下service中通常不使用try catch finally，本身處理的話，配置的事務處理就不起做用了。
3、殺手問題
11,看你的項目經歷，是開發企業應用居多，沒有互聯網和電商項目經驗。如今我問你若是是電商項目，你若是拆分紅分佈式項目。
這個問題直擊弱點，這裏其實已經不是考察能力是否匹配職位需求了，應該是爲優中選優準備的附加題。
我答不上來，就說了下我對本身項目分佈式拆分的思考，由於我從搭建本身項目那天開始就想着給企業全部幾萬用戶使用，腹稿早就有了。
而後推理電商項目中用戶、支付、交易記錄這些也註冊爲基礎服務。利用分佈式緩存提升性能，分佈式文件系統來存儲海量數據。
500強企業的專家級面試果真是變態，當時我不知道分佈式數據庫這個概念，致使後面被針對海量數據和分佈式數據庫攻擊。
12，前面說到海量數據，你對海量數據有哪些瞭解？
殺手問題果真是連環陷阱，就看你能闖過多少關得到加分了。還好我每次回答都注意答案出現的相關概念都至少是本身瞭解過的，以防護針對弱點攻擊。
我說海量數據加算法=大數據，講了幾個海量數據的典型算法，提到海量數據算法又順帶講了分佈式最終一致性那個二次提交確認的算法。
說到面試官不瞭解的領域再次被打斷了，面試官又問我下一個殺手問題。海量數據算法瞭解的標籤被加上。
13，咱們公司的的數據中心，常常會遇到短期寫入上百萬數據場景，你會怎麼處理？
答案應該是分佈式數據庫，前面沒提到分佈式數據庫，這裏再次被針對弱點提問,巧妙的隱藏概念,防止渾水摸魚。
開始我說用MQ消息隊列先消掉高併發峯值，向訂票系統那樣延後操做。面試官說要求實時處理，你這想法只是推遲。
我想了一下又說再加分佈式緩存，面試說仍是實時性不夠。
我忽然想到作單片機時，爲了提升數據傳輸量，增長多幾個IO口一塊兒來傳輸。講了到利用NIO的原理多增長端口來提升數據吞吐量。
一張大數量的表裏，如何取出10條數據
面試官說：「你對高併發，緩存瞭解多少？」
。。。。。。
面試官說：「SQL Server用的熟練嗎？一張大數量的表裏，如何取出10條數據。」
。。。。。。
面試官說：「你對Http協議瞭解的多嗎？」
。。。。。。
面試官說：「你對FastDFS瞭解嗎？」
此時通常會問到一些Java的基礎知識，好比
synchronized static修飾類和方法有什麼區別nginx

是同步修飾類表明是一個同步類,
HashMap的原理，底層數據結構，rehash的過程，指針碰撞問題git

HashMap爲何線程不安全(hash碰撞與擴容致使)

HashMap的線程安全問題，爲何會產生這樣的線程安全問題
ConcurrentHashMap的數據結構，底層原理，put和get是否線程安全
Java IO的一些內容，包括NIO，BIO等程序員

一、面向流與面向緩衝github

Java IO和NIO之間第一個最大的區別是，IO是面向流的，NIO是面向緩衝區的。 Java IO面向流意味着每次從流中讀一個或多個字節，直至讀取全部字節，它們沒有被緩存在任何地方。此外，它不能先後移動流中的數據。若是須要先後移動從流中讀取的數據，須要先將它緩存到一個緩衝區。 Java NIO的緩衝導向方法略有不一樣。數據讀取到一個它稍後處理的緩衝區，須要時可在緩衝區中先後移動。這就增長了處理過程當中的靈活性。可是，還須要檢查是否該緩衝區中包含全部您須要處理的數據。並且，需確保當更多的數據讀入緩衝區時，不要覆蓋緩衝區裏還沒有處理的數據。web

二、阻塞與非阻塞IO

Java IO的各類流是阻塞的。這意味着，當一個線程調用read() 或 write()時，該線程被阻塞，直到有一些數據被讀取，或數據徹底寫入。該線程在此期間不能再幹任何事情了。Java NIO的非阻塞模式，使一個線程從某通道發送請求讀取數據，可是它僅能獲得目前可用的數據，若是目前沒有數據可用時，就什麼都不會獲取，而不是保持線程阻塞，因此直至數據變的能夠讀取以前，該線程能夠繼續作其餘的事情。非阻塞寫也是如此。一個線程請求寫入一些數據到某通道，但不須要等待它徹底寫入，這個線程同時能夠去作別的事情。線程一般將非阻塞IO的空閒時間用於在其它通道上執行IO操做，因此一個單獨的線程如今能夠管理多個輸入和輸出通道（channel）。

三、選擇器（Selectors）

Java NIO的選擇器容許一個單獨的線程來監視多個輸入通道，你能夠註冊多個通道使用一個選擇器，而後使用一個單獨的線程來「選擇」通道：這些通道里已經有能夠處理的輸入，或者選擇已準備寫入的通道。這種選擇機制，使得一個單獨的線程很容易來管理多個通道。

3.1.2 Java高級特性
此時問到的問題通常包含JVM，多線程的一些內容，這塊建議你們多看看源碼，大體以下：
Java線程池的構造方法，裏面參數的含義，以及原理
volatile和ThreadLocal解決了什麼問題
CAS在Java中的具體實現
Java虛擬機的構成，以及一個Java對象的生命週期，還有堆棧和方法區中存儲的內容
JVM的GC過程，包括一些實際問題的分析，好比說明一個現象，讓你分析多是什麼緣由會致使這樣的問題，應該如何對JVM參數進行調優
synchronized和Lock的區別，以及底層實現原理
Full GC和Minor GC觸發的條件
GC Roots的選擇
jmap，jstat，jstack等的使用場景，MAT等
ClassLoader的加載過程
CountDownLatch、CyclicBarrier和Semaphore等
Java 8 的新特性等
3.1.3 數據庫
這裏的數據庫包含兩種，一種通常是MySQL，另外是NoSql數據庫，包括Redis、MongoDB等。通常會問的問題有：
inner join和left join等的區別
SQL調優，explain，profile等

ACID
數據庫的事務隔離級別，以及他們分別能解決什麼問題
Redis的幾種數據結構
Redis是單線程仍是多線程
Redis的持久化
悲觀鎖和樂觀鎖的含義
最左前綴索引，索引的數據結構，聚簇索引等（這塊還沒搞明白）
3.1.4 框架
3.1.4.1 Spring
由於spring是咱們經常使用的框架，因此這塊的內容會問的比較多，也會比較細。
Spring的兩大特性（IoC和AOP）
Spring的bean的生命週期
Spring是如何解決Bean的循環引用問題的
AOP的兩種實現方式，以及二者的區別（這裏其實使用了動態代理，具體動態代理分爲兩種，一種是JDK的動態代理，主要使用的是JDK的反射，還有一種是CGLib，二者區別能夠本身搜索，文章比較多）
AOP通常的使用場景
Spring的事務原理
3.1.4.2 MyBatis
這塊問到的比較簡單些：
$和#的區別
MyBatis和Hibernate的區別
3.1.4.3 Dubbo
由於平時本身用到了Dubbo，因此這塊會有問到：
RPC的原理
如前所述，RPC其實也是種C/S的編程模式，有點相似C/S Socket 編程模式，但要比它更高一層。
　　當咱們在創建RPC服務之後，客戶端的調用參數經過底層的RPC傳輸通道，能夠是UDP，也能夠是TCP，並根據傳輸前所提供的目的地址及RPC上層應用程序號轉至相應的RPC應用程序服務端，且此時的客戶端處於等待狀態，直至收到應答或Time Out超時信號。當服務器端得到請求消息，則會根據註冊RPC時告訴RPC系統的例程入口地址，執行相應的操做，並將結果返回至客戶端。
　　當一次RPC調用結束後，相應線程發送相應的信號，客戶端程序纔會繼續運行。
　　在這個過程當中，一個遠程過程是有三個要素來惟一肯定的：程序號、版本號和過程號。
　　程序號是用來區別一組相關的而且具備惟一過程好的遠程過程。一個程序能夠有一個或幾個不一樣的版本，而每一個版本的程序都包含一系列能被遠程調用的過程，經過版本的引入，使得不一樣版本下的RPC能同時提供服務。每一個版本都包含有許多可供遠程調用的過程，每一個過程則有其惟一標示的過程號。

1）服務消費方（client）調用以本地調用方式調用服務；
2）client stub接收到調用後負責將方法、參數等組裝成可以進行網絡傳輸的消息體；
3）client stub找到服務地址，並將消息發送到服務端；
4）server stub收到消息後進行解碼；
5）server stub根據解碼結果調用本地的服務；
6）本地服務執行並將結果返回給server stub；
7）server stub將返回結果打包成消息併發送至消費方；
8）client stub接收到消息，並進行解碼；
9）服務消費方獲得最終結果。

Dubbo是如何完成遠程調用的
serviceName serverAddressList clientAddressList
UserService 192.168.0.1，192.168.0.2，192.168.0.3，192.168.0.4 172.16.0.1，172.16.0.2
ProductService 192.168.0.3，192.168.0.4，192.168.0.5，192.168.0.6 172.16.0.2，172.16.0.3
OrderService 192.168.0.10，192.168.0.12，192.168.0.5，192.168.0.6 172.16.0.3，172.16.0.4
當某個Server不可用，那麼就更新受影響的服務對應的serverAddressList，即把這個Server從serverAddressList中踢出去（從地址列表中刪除），同時將推送serverAddressList給這些受影響的服務的clientAddressList裏面的全部Client。如：192.168.0.3掛了，那麼UserService和ProductService的serverAddressList都要把192.168.0.3刪除掉，同時把新的列表告訴對應的Client 172.16.0.1，172.16.0.2，172.16.0.3；
當某個Client掛了，那麼更新受影響的服務對應的clientAddressList
ConfigServer根據服務列表，就能提供一個web管理界面，來查看管理服務的提供者和使用者。
新加一個Server時，因爲它會主動與ConfigServer取得聯繫，而ConfigServer又會將這個信息主動發送給Client，因此新加一個Server時，只須要啓動Server，而後幾秒鐘內，Client就會使用上它提供的服務
Client
調用服務的機器，每一個Client啓動時，主動與ConfigServer創建Socket長鏈接，並將本身的IP等相應信息發送給ConfigServer。
Client在使用服務的時候根據服務名稱去ConfigServer中獲取服務提供者信息（這樣ConfigServer就知道某個服務是當前哪幾個Client在使用），Client拿到這些服務提供者信息後，與它們都創建鏈接，後面就能夠直接調用服務了，當有多個服務提供者的時候，Client根據必定的規則來進行負載均衡，如輪詢，隨機，按權重等。
一旦Client使用的服務它對應的服務提供者有變化（服務提供者有新增，刪除的狀況），ConfigServer就會把最新的服務提供者列表推送給Client，Client就會依據最新的服務提供者列表從新創建鏈接，新增的提供者創建鏈接，刪除的提供者丟棄鏈接
Server
真正提供服務的機器，每一個Server啓動時，主動與ConfigServer創建Scoket長鏈接，並將本身的IP，提供的服務名稱，端口等信息直接發送給ConfigServer，ConfigServer就會收集到每一個Server提供的服務的信息。

優勢：
1，只要在Client和Server啓動的時候，ConfigServer是好的，服務就可調用了，若是後面ConfigServer掛了，那隻影響ConfigServer掛了之後服務提供者有變化，而Client還沒法感知這一變化。
2，Client每次調用服務是不通過ConfigServer的，Client只是與它創建聯繫，從它那裏獲取提供服務者列表而已
3，調用服務-負載均衡：Client調用服務時，能夠根據規則在多個服務提供者之間輪流調用服務。
4，服務提供者-容災：某一個Server掛了，Client依然是能夠正確的調用服務的，當前提是這個服務有至少2個服務提供者，Client能很快的感知到服務提供者的變化，並做出相應反應。
5，服務提供者-擴展：添加一個服務提供者很容易，並且Client會很快的感知到它的存在並使用它。

Dubbo如何進行調優
 超時: 服務消費方, 訪問服務提供方應該設置一個超時時間, 若是開發階段, 在服務提供方設置debug,
 進行調試, 會有一段時間不能返回結果, 這樣會致使服務消費方報錯. 因此超時時間應該儘量設置的長一點.

 直接鏈接: 在線上, 須要zookeeper來協調服務提供方, 由於服務提供方有多是一個幾百臺機器的集羣, 這樣服務消費
 方在調用提供方的時候就不知道服務提供方的機器的ip和端口, 因此須要zookeeper進行協調.
 在本地開發階段, 就一個服務提供方, 一個服務消費方, 不是集羣, 因此將服務消費方直接鏈接到服務提供方
 就能夠, 這樣能夠省去一個虛擬機, 是本地開發機器性能提升.

 服務消費方不檢查服務提供方: 設置服務消費方在啓動的時候不檢查服務提供方有沒有啓動, 在使用的時候再去檢查 ,
 這樣就能夠不管先啓動服務提供方仍是消費方, 均可以.
Dubbo的通訊協議
Dubbo RPC服務框架支持豐富的傳輸協議、序列化方式等通信相關的配置和擴展。dubbo執行一次RPC請求的過程大體以下：消費者（Consumer）向註冊中心（Registry）執行RPC請求，註冊中心分配服務URL並路由到具體服務提供方（Provider），消費者和服務提供方創建網絡鏈接，服務提供方在本地建立鏈接池對象並提供遠程服務，對於長鏈接類型協議（如dubbo協議）將保持鏈接，減小握手認證，調用過程當中能夠避免頻繁創建和斷開鏈接致使的性能開銷，保持長鏈接須要有心跳包的發送，因此對於非頻繁調用的服務保持鏈接一樣會有消耗。更多關於dubbo詳細介紹請參照官方文檔（http://alibaba.github.io/dubbo-doc-static/Home-zh.htm）。
　　一、支持常見的傳輸協議：RMI、Dubbo、Hessain、WebService、Http等，其中Dubbo和RMI協議基於TCP實現，Hessian和WebService基於HTTP實現。
　　二、傳輸框架：Netty、Mina、以及基於servlet等方式。
　　三、序列化方式：Hessian二、dubbo、JSON（fastjson 實現）、JAVA、SOAP 等。
　　本文主要基於dubbo框架下的通信協議進行性能測試對比。

Dubbo是如何實現負載均衡的
默認的負載方式是隨機負載均衡（@SPI(RandomLoadBalance.NAME)），咱們也能夠指定使用哪一種負載均衡：
<dubbo:reference interface="xxx" loadbalance="roundrobin"/> 或 <dubbo:service interface="xxx" loadbalance="roundrobin" />

確定有人會問，普通的隨機負載均衡和輪詢的負載均衡方式效果不是同樣的嗎？確實，若是是普通的隨機，理論上來講和輪詢的方式效果一致，甚至有時候還不如輪詢的好，由於這和採起的隨機數的隨機程度和隨機數生成開銷兩種因素有關，但若是在隨機過程當中加入權重這一屬性的話，隨機的優點不言而喻了，好比能夠作到「預熱」功能，給剛上的服務器在某段時間內分配比其餘服務器更少的請求，讓剛上的服務器能先「熱熱身」，這一點，普通輪詢方式是很難作到的。沒錯，Dubbo默認的隨機負載方式就加入了權重這一因數，權重精確到某個接口的某個方法，這也是咱們所指望的，其默認「預熱」時間是10分鐘。

Dubbo中有個抽象類AbstractLoadBalance，它實現了獲取某個接口某個方法的權重值，預熱部分的計算也包含在其中，這裏代碼就不貼出來了，之因此Dubbo這樣作，是由於其餘負載形式都用到權重因子。

咱們這裏簡單描述下各類負載均衡的實現方式：
隨機負載均衡（RandomLoadBalance）：先統計全部服務器上該接口方法的權重總和，而後對這個總和隨機nextInt一下，看生成的隨機數落到哪一個段內，就調哪一個服務器上的該服務。
輪詢負載均衡（RoundRobinLoadBalance）：若是全部服務器的該接口方法的權重同樣，則直接內部的序列計數器（sequences）+1而後對服務器的數量進行取模來決定調用哪一個服務器上的服務；若是服務器的該接口方法的權重不同（就是說存在預熱中的服務器），則找到其中最大的權重，而後將內部的權重計數器（weightSequences）+1並對該最大權重數取模，而後再找出權重比該取模後的值大服務器列表，最後經過內部的序列計數器（sequences）+1而後對服務器列表數量進行取模來決定調用哪一個服務器上的服務。
最少活躍負載均衡（LeastActiveLoadBalance）：每一個接口和接口方法都對應一個RpcStatus對象，記錄了他們的活躍數、失敗數等等相關統計信息，此種負載均衡方式是在活躍數最低的服務器中對其權重的總和取模來看結果是在哪一個權重段中，則選擇該服務器來調用，活躍數就像併發量降級中的計數器同樣，開始調用時活躍數+1，調用結束時活躍數-1，因此活躍值越大，代表該提供者服務器的該接口方法耗時越長，而消費能力強的提供者接口每每活躍值很低。最少活躍負載均衡保證了「慢」提供者能接收到更少的服務器調用。
一致哈希負載均衡（ConsistentHashLoadBalance）：一致性哈希算法的負載均衡保證了一樣的請求（參數）將會落到同一臺服務器上，這在某些場景是很是有用的，Dubbo中默認採用了160個虛擬節點，由於Dubbo的請求URL中除了咱們使用的參數，還有些額外的系統調用參數，好比timestamp、loadbalance、pid和application等，有人可定會問，Dubbo會對URL中哪些參數進行hash，Dubbo默認除了對咱們接口全部參數進行hash外，還會加上這些額外參數，由於有timestamp，這是否是也意味着在Dubbo的重試調用時timestamp不變？

上述的四種負載均衡，除了一致性哈希，其餘三種都依賴了接口方法的權重統計，藉助權重的不一樣，隨機負載均衡就能作到動態調整的效果，Dubbo中的輪詢負載方式，也利用了權重，那麼有人會問，Dubbo中的隨機和輪詢是否是差異不大？是的，筆者也這樣認爲，類似的效果，也有着類似的缺點，Dubbo中的隨機和輪詢負載都沒有考慮到提供者服務器消費服務的能力，若是相差很大，「慢」提供者有可能被「快」提供給者給拖垮，其根本緣由也是這兩種負載均衡的加權因子考慮的不是服務耗時。最少活躍的負載均衡就很巧妙的解決了此問題，並且它不是直接經過統計服務調用的耗時，而是採用統計調用差（活躍數）。一致性哈希特別適用於有緩存的系統，這樣緩存命中率會比較高。
能夠自行擴展負載均衡策略，參見：負載均衡擴展

Random LoadBalance
隨機，按權重設置隨機機率。
在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

權重加倍

RoundRobin LoadBalance
輪循，按公約後的權重設置輪循比率。
存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。
解決辦法 :結合權重，把第二臺機(性能低的)的權重設置低一點

LeastActive LoadBalance
最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。
使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

ConsistentHash LoadBalance
一致性Hash，相同參數的請求老是發到同一提供者。
當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
算法參見：http://en.wikipedia.org/wiki/Consistent_hashing。
缺省只對第一個參數Hash，若是要修改，請配置<dubbo:parameter key="hash.arguments" value="0,1" />
缺省用160份虛擬節點，若是要修改，請配置<dubbo:parameter key="hash.nodes" value="320" />

Dubbo管理臺配置負載均衡

權重調節

配置如：
<dubbo:serviceinterface="..."loadbalance="roundrobin"/>
或：
<dubbo:referenceinterface="..."loadbalance="roundrobin"/>
或：
<dubbo:serviceinterface="...">
<dubbo:methodname="..."loadbalance="roundrobin"/>
</dubbo:service>
通常在實際項目咱們配置權重或負載均衡時不在代碼中寫死，咱們動態使用默認配置，須要調節時經過dubbo管控臺上進行配置
或：
<dubbo:referenceinterface="...">
<dubbo:methodname="..."loadbalance="roundrobin"/>
</dubbo:reference>

3.1.4.4 ZooKeeper
ZK的使用場景
ZK的選舉機制
ZK的節點類型
一致性Hash原理
3.1.5 數據結構和算法
這塊的內容是基礎，若是面試官懷疑你的能力，通常一會問到這部份內容，好比樹的遍歷、快速排序等。
3.1.6 linux
通常會問一些命令的使用，而後會舉一個實際的場景，讓你用命令去排查問題，這塊本身不是很熟，須要儘快增強。
3.1.7 綜合題
這塊的題目，面試官通常會問的比較深刻。好比如何設計一個搶購系統，String轉Integer等，這部分須要考驗的就是一我的的臨場應變能力，以及在平時工做中系統設計能力的積累，以及考慮問題是否周到等。也有可能會對你簡歷上面寫的系統的設計進行詳細的詢問，因此在你寫簡歷的時候，千萬不能把本身不熟悉的內容寫上去，並且本身又講不清，這樣通常會被直接pass掉。
固然也會問一些經常使用的maven的命令，設計模式的題目（這部分問的比較多的就是單例模式）。

一、 JAVA基礎
1)      抽象類和接口的區別？
補充問題：JAVA8中爲何要加入默認方法？
2)      靜態內部類(static class)的做用？
3)      序列化和反序列化
4)      動態代理和靜態代理的區別？
贈送問題：代理模式，什麼是代理模式？如何實現？代理模式結構圖是怎樣的？代理模式應用在什麼場景？
5)      nio熟悉嗎，nio和io的區別？
6)      java8有哪些新特性？
二、 Java API
1)      transient關鍵字的做用？
2)      volatile關鍵字的做用？
3)      abstract和final是否可同時使用？
4)      ArrayList、LinkedList、vector的區別？
5)      HashMap、LinkedHashMap，concurrentHashMap的區別，concurrentHashMap爲何特別好用，你看過源碼嗎？
6)      collection的繼承結構，你是否看過源碼？
三、 JVM調優(性能)
1)      有哪些調優工具
2)      如何快速定位有問題代碼
3)      內存溢出如何處理，如何調優
4)      垃圾回收機制，有哪些垃圾回收算法，如何配置垃圾回收策略
5)      新生代和老年代
四、 Tomcat
tomcat能夠穩定支持的最大併發用戶數
Tomcat集羣如何架設：Tomcat+Apache
集羣時特別關注兩個問題：
1：如何實現多應用服務器間的session共享：（一臺服務器崩潰，另一臺服務器能夠繼續支持）
2：如何分發請求到各個應用服務器實現壓力分解：（這裏的解決方案是用apache作 web服務器）

算法問題
一、生產者和消費者問題？
二、查找算法有幾種，寫出實現代碼？
三、排序算法有幾種，寫出實現代碼？
四、遍歷二叉樹，分別按照前序、中序、後續？
五、紅黑樹
程序題
一、寫出一個字符串，打印出字符串中字符的全部排序
二、無序的有重複數據的list變成有序的無重複數據的list

框架篇
一、 spring核心：
分別說說aop和IOC
事務配置的幾種方式？
spring有幾種注入方式？
spring依賴注入的四種裝配方式？
spring的幾個重要註解@Component（不推薦使用）、@Repository、@Service、@Controller
二、 SpringMVC和Struts2：二者的區別
三、 Mybatis和hibernate：二者的區別
           mybatis如何實現多表關聯查詢
           mybatis的resultMap
           mybatis的#和$
四、是否能夠用maven搭建項目，maven如何構建web項目？
五、 Git的使用
六、當日志很是大時，如何查找須要的日誌？
七、 SSH的侷限有哪些
數據庫篇
數據庫基礎
一、 MySQL和Oracle的區別

mysql能夠設置主鍵自增策略 oracle 是經過序列來主鍵自增

5、提交方式
oracle默認事務不自動提交，須要用戶手動提交。
mysql默認是自動提交。

mysql默認讀已提交 oracle 串行化

mysql:
mysql以表級鎖爲主，對資源鎖定的粒度很大，若是一個session對一個表加鎖時間過長，會讓其餘session沒法更新此表中的數據。
雖然InnoDB引擎的表能夠用行級鎖，但這個行級鎖的機制依賴於表的索引，若是表沒有索引，或者sql語句沒有使用索引，那麼仍然使用表級鎖。

二、 oracle移植到mysql須要處理哪些
三、存儲過程

體如今：
1.存儲過程只在創造時進行編譯，之後每次執行存儲過程都不需再從新編譯，而通常 SQL 語句每執行一次就編譯一次,因此使用存儲過程可提升數據庫執行速度。
2.當對數據庫進行復雜操做時(如對多個表進行 Update,Insert,Query,Delete 時），可將此複雜操做用存儲過程封裝起來與數據庫提供的事務處理結合一塊兒使用。這些操做，若是用程序來完成，就變成了一條條的 SQL 語句，可能要屢次鏈接數據庫。而換成存儲，只須要鏈接一次數據庫就能夠了。
3.存儲過程能夠重複使用,可減小數據庫開發人員的工做量。
4.安全性高,可設定只有某此用戶才具備對指定存儲過程的使用權。
四、 mysql存儲引擎innodb和myisam的區別

MyISAM、InnoDB區別引擎

l MyISAM類型不支持事務處理等高級處理，而InnoDB類型支持。

l MyISAM表不支持外鍵，InnoDB支持

l MyISAM鎖的粒度是表級，而InnoDB支持行級鎖定。

l MyISAM支持全文類型索引，而InnoDB不支持全文索引。(mysql 5.6後innodb支持全文索引)

MyISAM相對簡單，因此在效率上要優於InnoDB，小型應用能夠考慮使用MyISAM。當你的數據庫有大量的寫入、更新操做而查詢比較少或者數據完整性要求比較高的時

候就選擇innodb表。當你的數據庫主要以查詢爲主，相比較而言更新和寫入比較少，而且業務方面數據完整性要求不那麼嚴格，就選擇mysiam表。

、一張表,裏面有ID自增主鍵,當insert了17條記錄以後,刪除了第15,16,17條記錄,再把Mysql重啓,再insert一條記錄,這條記錄的ID是18仍是15 ？(區分兩種數據庫引擎)

（1）若是表的類型是MyISAM，那麼是18。
由於MyISAM表會把自增主鍵的最大ID記錄到數據文件裏，重啓MySQL自增主鍵的最大ID也不會丟失。數據和索引單獨的文件
（2）若是表的類型是InnoDB，那麼是15。
InnoDB表只是把自增主鍵的最大ID記錄到內存中，因此重啓數據庫或者是對錶進行OPTIMIZE操做，都會致使最大ID丟失。由於數據和索引同一個文件

數據庫優化
一、 sql優化
二、索引
關於索引：聯合索引A和B，當按照A、A和B、B查詢時索引使用狀況？
三、數據庫優化，使用過哪些優化工具：經常使用的SQLYOG、基準測試，expain、status等
具體問題：
           如何找到並定位慢SQL？
           如何肯定表和查詢是不是最優的？
           枚舉類型如何使用，枚舉類型的誤用帶來的損失？
有沒有什麼工具能夠監控數據庫，快速查看有問題的sql?若是存在大批量有問題的sql，如何排查？
如何診斷響應差的(太多線程)，殭屍進程(無響應或長時間運行)，或者診斷鏈接問題？
若是在某段時間內用戶反映服務器變慢，如何知道服務器性能差？
           假設已經檢查了全部常規信息——內存、磁盤等，而全部這些信息都在正常範圍內，沒有出現錯誤和異常，這時，你怎麼知道系統是否運行變慢？

數據庫進階
一、當數據庫存儲數據出現瓶頸，如何處理？——數據庫水平拆分、垂直拆分
二、說說水平拆分和垂直拆分，何時水平拆分，何時垂直拆分，分別解決了哪些問題，分別存在哪些不能解決的問題，如何結合使用？
三、當水平拆分時，到不一樣的表和庫中或不一樣的分佈式服務器上時：不一樣的表能夠聯合查詢(union)、不一樣的庫能夠加上庫名進行聯合查詢；若是須要查詢的數據分佈在不一樣的服務器之間，如何查詢？如何在存儲數據時就將須要同時查詢的數據放在同一服務器上(存儲時取模或者按照時間分佈數據，查詢的時候取模或者按照時間查詢)
四、 mysql讀寫分離
五、數據庫集羣

升級篇
分佈式
一、有哪些分佈式框架，對比其性能優劣？
同步調用：RSET(JAX-RS、Spring Boot)、RPC(Thrift、Dubbo、HSF)
異步調用：Kafka、Notify、MetaQ
同步和異步的區別，分別用於什麼場景？
二、 dubbo + zookeeper
三、 nosql(Redis、memcache、MongoDB)

大併發的處理
一、負載均衡
二、分佈式
三、緩存
四、數據庫分庫分表
五、數據庫集羣
六、圖片服務器分離
七、首頁靜態化

大數據問題：
假如天天產生5億行日誌文件，如何搜索到指定內容？
有一個100T大小的文件存放在磁盤中，不借助任何外部存儲設備，如何統計指定字符串的個數？
同上，有一個文件，存放天天訪問的URL，天天有100萬條，如何統計URL的個數？
測試1000萬條數據的查詢

多線程
一、有哪些多線程的應用場景

舉一個小栗子：

一個文本文件有100M，全是字符串，我要執行切分字符串，每達到N長度便執行切腹，最後求切分完成的字符串的集合

單線程處理：讀取文本文件數據，掃描所有數據，一個一個的切分，最後消耗時間=文件傳輸時間(文本數據加載到內存)+切分過程消耗

多線程處理：

專門設置一個線程執行加載數據的操做，此時，若是加載的數據達到一個設定值，啓動一個切線程處理，如此繼續，多個切分字符串的線程可以併發執行，CPU的利用率提升了(文件傳輸的過程當中沒有佔用處理器，而能夠將加載的部分數據分配給切分線程，佔用處理器來執行任務)

總結：

單線程處理，文件加載的過程當中，處理器一直空閒，但也被加入到總執行時間以內，串行執行切分總時間，等於每切分一個時間*切分後字符串的個數，執行程序，估計等幾分鐘能處理完就不錯了

多線程處理，文件加載過程與拆分過程，拆分過程與拆分過程，都存在併發——文件加載的過程當中就執行了切分任務，切分任務執行過程當中多線程並行處理，總消耗時間能比單線程提升不少，甚至幾個數量級都不止。

二、你本身有寫過多線程嗎，在哪些場景
三、線程池,java提供的線程池有哪幾種？
四、隊列
五、 servlet是線程安全的嗎，如何改進？

不是
六、實現同步的幾種方式?

安全
關於安全方面作了哪些工做？

用shiro框架對權限進行校驗, 密碼經過md5進行加密
手機、支付如何保證信息安全？
sql注入問題
如何保證訪問URL安全：如何不暴露真實的URL地址；如何防止篡改URL地址；如何防止在URL中SQL注入？

設計模式
一、你熟悉哪些設計模式
二、框架中用到哪些設計模式
           java IO：裝飾器模式(Decorator)、適配器模式(Adapt)
           Spring ：訪問者模式(Visitor)、代理模式(Proxy)、策略模式(Strategy)
           SpringMVC：模版模式(TempleteMethod) JDBCTemplete 模板模式省去了在代碼中try catch finally
           Mybatis：簡單工廠模式、工廠方法模式(FactoryMethod)、抽象工廠模式(Abstract Factory)
           Tomcat：門面模式、觀察者模式(Observer)、命令模式(Command)、責任鏈模式(chainof responsible)
           Velocity ：合成模式
三、裝飾模式和適配器模式的區別

適配器模式一個接口適配到另外一個接口造成一個新接口例如字節流到字符流的轉換

裝飾模式裝飾模式就是給一個對象增長一些新的功能，並且是動態的，要求裝飾對象和被裝飾對象實現同一個接口例如 FileInpustream 實現Inpustream接口 BuffereInpustream 實現 Inpustream BuffereInpustream對 FileInpustream進行加強
四、寫一個單例模式

Linux
一、會使用哪些命令
查看端口是否被佔用

netstat -anp |grep 3306
如何查看指定的日誌

一、tail -f filename 說明：監視filename文件的尾部內容（默認10行，至關於增長參數 -n 10），刷新顯示在屏幕上。退出，按下CTRL+C。二、tail -n 20 filename 說明：顯示filename最後20行。

網絡
一、通訊協議是否有了解，TCP/UDP等、HTTP
二、 http反向代理

業務篇
一、訂單：大量併發問題