1，java堆，分新生代老年代，新生代有Eden，from surviver，to surviver三個空間，堆被所有線程共。eden內存不足時，發生一次minor GC，會把from survivor和eden的對象復制到to survivor，這次的to?survivor就變成了下次的from survivor，經過多次minor GC，默認15次，達到次數的對象會從survivor進行老年代。1次new如果新生代裝不下，則直接進入老年代。

2，HashMap和HashTable是使用數組+鏈表結構實現，根據Hash和table長度計算數組的下標index做操作，hashMap默認數組長度為16，hashMap對null值的key都放在table[0]的位置，table[index]形成1個鏈表，當然在新版jdk中鏈表節點數>8會變成紅黑樹結構。hashMap達到最大數量會擴容，擴容table長度變為2倍，每個元素（table中）但重新計算index放到新的table中。

3，堆的年輕代和老年代。

堆的年輕代大則老年代小，GC少，但是每次時間會比較長。年輕代小則老年代大，會縮短每次GC的時間，但是次數頻繁。可以讓老年代盡量緩存常用對象，JVM默認年輕代和老年代的大小比例為1:2,。觀察峰值老年代內存，不影響full GC，加大老年代可調1:1，但是要給老年代預留三分之一的空間。減少使用全局變量和大對象 ，調整新生代，老年代到最合適。

4，字節流不會用到內存緩沖區，文件本身直接操作。字符流操作使用內存緩存區，用緩存存操作文件。字符流在輸出前將所有內容暫時保存到內存中，即緩存區暫時存儲，如果想不關閉也將字符流輸出則可以使用flush方法強制刷出。字節字符轉化可能存在系統編碼lang，要制定編碼。getbyte字節流使用更加廣泛。

5，中文占用2個字節，read()函數讀1個字節把A會讀入的原因。ASCII碼是8位，A在ASCII碼中有對應碼，A只要8位就能表示，但是unicode是支持ASCII碼的，在unicode中表示A是使用低8位的ASCII碼，補上高8位的0，read()1分字節就已經讀入A的ASCII碼，打印時會給其高8位補上0，所以顯示正常A。

6，喚醒一個阻塞的線程

如因為Sleep，wait，join等阻塞，可以使用interrupted exception異常喚醒。

7，內存溢出可能原因和解決。

原因可能是A，數據加載過多，如1次從數據庫中取出過多數據 ? B，集合類中有對對象的引用，用完后沒有清空或者集合對象未置空導致引用存在等，是的JVM無法回收 ?C，死循環，過多重復對象 D，第三方軟件的bug ? ? ? E，啟動參數內存值設定的過小。

例如方法：修改JVM啟動參數，加內存(-Xms，-Xmx)；錯誤日志，是否還有其他錯誤；代碼走查

8，redis使用單線程模型，數據順序提交，redis支持主從模式，mencache只支持一致性hash做分布式；redis支持數據落地，rdb定時快照和aof實時記錄操作命令的日志備份，memcache不支持；redis數據類型豐富，有string，hash，set，list， sort set，而memcache只支持簡單數據類型；memcache使用cas樂觀鎖做一致性。

jedis操作Hash：hmset, hmget, hdel, hkeys

jedis操作List： lpush，lrange按照范圍取出，rpush， del， sort等keyjedis操作Set：sadd，srem移除noname，smembers， sismember， scard等。

使用場景例如

Hash：存儲讀取更新用戶多個屬性

List：微博TimeLine，消息列表

Set：共同好友，二度好友，用唯一性可以統計網站所有獨立IP，好友推薦根據tag求交集，大于threshold就可以推薦。

sortset：set增加1個權重score參數

其他場景：A訂閱發布系統，redis對某個key消息發布及訂閱，當1個key消息發布后，所有訂閱它的客戶端都會收到相應消息，例如實時消息系統，即時聊天，群聊等。

事務-常用EX,EC提交執行的命令，在server不出問題，可以保證一連串的命令是順序執行額；提供1個watch功能，對1個key作watch，然后再執行transation。

?

?

9，Class.forName()將類加載到JVM，還會對類解釋，執行static塊，而ClassLoader也加載到JVM，但是不會執行static塊，并且只有調用了new Instance方法才會調用構造函數。

10，java反射機制。

可以在運行時判斷一個對象所屬的類，構造一個類的對象，判斷類具有的成員變量和方法，調用1個對象的方法。4個關鍵的類：Class，Constructor，Field，Method。 ? ?getConstructor獲得構造函數/getDeclardConstructor； getField/getFields/getDeclardFields獲得類所生命的所有字段；getMethod/getMethods/getDeclardMethod獲得類聲明的所有方法，正常方法是一個類創建對象，而反射是1個對象找到1個類。

11，Object類中的方法：clone()，但是使用該方法必須實現Java.lang.Cloneable接口，equal()方法判斷引用是否一致，指向同一對象，即相等于==，只有覆寫了equals()方法之后，才可以說不同。hashcode()，對象的地址， toString()， finalize()。

12，序列化和反序列化

序列化和反序列化即對象和字節序列間的轉化，進程間傳送文本圖片音頻等以二進制傳送。JDK中ObjectOuputStream和ObjectInputStream為輸出輸入流，只有實現SeriaLizable/Externalizable接口的類才能被序列化。如Person對象傳遞給內存流使用DataConstractJsonSeralizer， MemoryStream stream = new MemoryStream();?DataConstractJsonSeralizer SER = new?DataConstractJsonSeralizer(typeof(person)); ?ser.writeObjectStream(stream, person);顯示json輸出，StramReader sr = new StreamReader(stream1); sr.ReadToEnd()。

13，講講分布式唯一ID。

確定ID存儲用64位，1個64位二進制1是這樣的00000000.....1100......0101，切割64位，某段二進制表示成1個約束條件，前41位為毫秒時間，后緊接9位為IP，IP之后為自增的二進制，記錄當前面位數相同情況下是第幾個id，如現在有10臺機器，這個id生成器生成id極限是同臺機器1ms內生成2的14次方個ID。

分布式唯一ID = 時間戳 << 41位， int類型服務器編號 << 10，序列自增sequence。每個時間戳內只能生成固定數量如（10萬）個自增號，達到最大值則同步等待下個時間戳，自增從0開始。將毫秒數放在最高位，保證生成的ID是趨勢遞增的，每個業務線、每個機房、每個機器生成的ID都是不同的。如39bit毫秒數|4bit業務線|2bit機房|預留|7bit序列號。高位取2016年1月1日1到現在的毫秒數，系統運行10年，至少需要10年x365天x24小時x3600秒x1000毫秒=320x10~9，差不多39bit給毫秒數，每秒單機高峰并發小于100，差不多7bit給每毫秒的自增號，5年內機房小于100臺機器，預留2bit給機房，每個機房小于100臺機器，預留7bit給每個機房，業務線小于10個，預留4bit給業務線標識。

64bit分布式ID（42bit毫秒+5bit機器ID+12位自增）等

生成分布式ID的方式：A，2個自增表，步長相互隔開 ? B，時間的毫秒或者納秒 ?C，UUID ? ? ? ? D，64位約束條件（如上）

14，NIO和IO的區別

第一點，NIO少了1次從內核空間到用戶空間的拷貝。

ByteBuffer.allocateDirect()分配的內存使用的是本機內存而不是Java堆上的內存，和網絡或者磁盤交互都在操作系統的內核空間中發生。allocateDirect()的區別在于這塊內存不由java堆管理, 但仍然在同一用戶進程內。

第二點，NIO以塊處理數據，IO以流處理數據

第三點，非阻塞，NIO1個線程可以管理多個輸入輸出通道

15，內存泄漏

未對作廢數據內存單元置為null，盡早釋放無用對象的引用，使用臨時變量時，讓引用變量在推出活動域后自動設置為null，暗示垃圾收集器收集；程序避免用String拼接，用StringBuffer，因為每個String會占用內存一塊區域；盡量少用靜態變量（全局不會回收）；不要集中創建對象尤其大對象，可以使用流操作；盡量使用對象池，不再循環中創建對象，優化配置；創建對象到單例getInstance中，對象無法回收被單例引用；服務器session時間設置過長也會引起內存泄漏。

16，對象克隆和實現方式

克隆的對象可能包含一些已經修改過的屬性，而new1個對象屬性都還是初始化時候的值，被復制克隆的類要實現Clonable接口，覆蓋clone()方法，訪問修飾符為public，方法中調用super.clone()得到所需要的復制方法，類中的屬性類也需要實現Clonable接口，覆寫clone()方法，并在super中也調用子屬性類的clone()復制，才可以實現深拷貝。

或者寫到流中序列化的方式來實現，不必考慮引用類型中還包含引用類型，直接用序列化來實現對象的深復制拷貝，即將對象寫到流，再從流中讀出來，需要實現seriazation接口。

17，redis內存數據上升到一定大小會執行數據淘汰策略，redis提供了6種數據淘汰策略。

LRU：從已設置過期時間的數據集合中挑選最近最少使用的數據淘汰

random：從已設置過期時間的數據中挑選任意數據淘汰

ttl：從已設置過期時間的數據集合中挑選將要過期的數據淘汰。

notenvision：禁止驅逐數據

如mysql中有2千萬數據，redis只存儲20萬的熱門數據。LRU或者TTL都滿足熱點數據讀取較多，不太可能超時特點。

redis特點：速度塊，O(1)，豐富的數據類型，支持事物原子性，可用于緩存，比memecache速度塊，可以持久化數據。

常見問題和解決：Master最好不做持久化如RDB快照和AOF日志文件；如果數據比較重要，某分slave開啟AOF備份數據，策略為每秒1次，為了主從復制速度及穩定，MS主從在同一局域網內；主從復制不要用圖狀結構，用單向鏈表更為穩定 M-S-S-S-S。。。。；redis過期采用懶漢+定期，懶漢即get/set時候檢查key是否過期，過期則刪除key，定期遍歷每個DB，檢查制定個數個key；結合服務器性能調節并發情況。

過期淘汰，數據寫入redis會附帶1個有效時間，這個有效時間內該數據被認為是正確的并不關心真實情況，例如對支付等業務采用版本號實現，redis中每一份數據都維持1個版本號，DB中也維持1份，只有當redis的與DB中的版本一致時，才會認為redis為有效的，不過仍然每次都要訪問DB，只需要查詢version版本字段即可。

18，異步化，生產接口每秒鐘10萬并發，消費者用異步慢慢消費。緩存模式空間換時間，把1兩億的數據名單打到緩存。服務降級，把不重要的任務放棄；靜態資源離線包下載機制，在wify下會主動提前把靜態下載前端層保護可請將用戶請求延長，點擊后主動給它隨機等待2s的時間/2分鐘之內不能請求；后端做部分接口的開關，設置超短耗時時間，原來只用5ms的只給20ms。

系統一段時間內會自動重試，重試多次后就認為是失敗了，檢查支付接口返回該訂單的錢，支付操作如果回復錯誤則回滾扣庫存的事務，沒返回則會記錄進行中pendding狀態，結束整個過程，等通知失敗/成功，AB系統之間會出現死循環補償，如B退單不成功，一般就是記錄錯誤日志了。超時每隔一段時間去定時回調服務定時回滾，一定次數還是超時則提示用戶聯系客服，訂單庫存可以不會滾，記錄狀態，如果一直調用支付不成功，則讓用戶自己去處理聯系客服，可以不回滾用戶的數據，金額扣了才算真正完成，是一種簡單粗暴的做法。

公共配置抽象成存儲到zookeeper配置中心或者redis等，DB也存儲一份，各應用監聽ZK的配置變化，可以建一個配置web管理頁面。

19，dubbo用ProxyFactoty代理工廠將HelloServiceImpl封裝成1個Inoke執行，即ProxyFactory.getInvoke(ref, (Class)接口，注冊URL，解碼參數)，并將Invoke導出成1個Exporter，包括去注冊中心ZK注冊服務。Invoke有本地執行的Invoke，遠程通信執行的Invoke。

20，每次扣減庫存時加上1個請求流水編號，上層請求扣減庫存沒拿到結果的話，重新查詢1次做重試操作，量不大都是加鎖處理。減少鎖的時間，犧牲冪等性，扣減為DB下地操作，查詢扣減和設置合成1步，中間沒有網絡請求。利用緩存，通過寫log記錄操作，異步合并日志及更新，重啟時cache失效，讀log恢復，避免重復提交，寫操作不建議重試快速失敗。多個商品同時增減庫存，可使用訂單號做冪等處理，應用層對單個商品減庫存，操作排隊，商品消息ID路由在1個應用server處理，讀本地緩存，失效再redis，DB采用樂觀鎖，組提交，1次減庫存多個訂單的購買量。可將同一個key下庫存m分為n組k1......kn，每組數為m/n，扣減依次在各組扣減，減少并發沖突。隊列裝滿后關閉隊列進入，然后用戶輪訓自己是否搶到了異步ajax，用戶資源隊列固定長度。2個隊列，1個銷售的資源隊列放入redis，有另外1個隊列用來裝搶購的會員的uid。

紅包狀態正常，并成功將狀態改為“已領取”，且消息發送成功，用戶端開始消費該消息，如果消費失敗/超時，用MQ做重試做冪等，直到成功，每條消息有唯一編號且保證消息處理成功與去重表的日志同時出現。

熱點將hot data拆分，分在不同庫和不同表，分散熱點Data，減輕DB并發更新熱點帶來RT升高和應用連接超時。SQL在mysql層加以限制，SQL超時/thradrunning到1定值則拒絕SQL執行，一定時間異步將結果寫入DB，nginx對IP做限制，可能誤殺。

21，SpringAOP，XML配置<aop:config>，切面<aop:aspect>切點<aop:pointcut>，連接切點和通知方法<aop:before>和<aop:after>等，注解可以直接使用@before執行方法@after ，@before(“pointcut()”) ，@after("pointcut")， @Aroud("excutete())，@AfteReturning，@AfterThrowing，可作日志事務，權限等待，AOP即通過把具體的類創建對應的 代理類，從代理類來對具體進行操作。 ? ? ? ? ? ? ? ? ? ? ?

目標實現了接口，默認采用JDK實現AOP，也可以強制使用CGlib來實現AOP，目標沒有實現接口的話，則必須采用CGlib，Spring自動在JDK和CGlib切換。如果要求spring強制使用CGlib實現AOP，則可以配置，添加Cglib庫。。。jar， Spring配置文件中加入<aop:aspecj-autoproxy proxy-target-Class=true> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??

22，MyISM采用表級鎖，對Myism表讀不會阻塞讀，會阻塞同表寫，對Myism寫則會阻塞讀和寫，即一個線程獲得1個表的寫鎖后，只有持有鎖的線程可以對表更新操作，其他線程的讀和寫都會等待。

InnoDB，采用行級鎖，支持事務，例如只對a列加索引，如果update ...where a=1 and b=2其實也會鎖整個表， select 使用共享鎖，update insert delete采用排它鎖，commit會把鎖取消，當然select by id for update也可以制定排它鎖。

23，實時隊列采用雙隊列模式，生產者將行為記錄寫入Queue1，worker服務從Queue1消費新鮮數據，如果異常則寫入Queue2（主要保存異常數據），RetryWorker會監聽Queue2，消費異常數據，如果還未處理成功按照一定的策略等待或者將異常數據再寫入Queue2，如果數據發生積壓可以調整worker的消費游標，從最新數據重新開始消費，保證了最新data得到處理，中間未處理的一段則可以啟動backupWorker指定起止游標在消費完指定區間的數據后，backupWorker會自動停止。

DB降級開關后，可直接寫入redis（storm），同時將數據寫入一份到Retry隊列，在開啟DB降級開關后消費Retry隊列中的數據，從而把數據寫入到mysql中，達到最終一致性。MYSQL切分為分片為2的N次方，例如原來分為兩個庫d0和d1均放在s0服務器上，s0同時有備機s1，擴容只要幾步驟：確保s0到s1服務器同步順利，沒有明顯延遲；s0暫時關閉讀寫權限；確保s1已經完全同步到s0更新；s1開放讀寫權限；d1的dns由s0切換到s1；s0開放讀寫權限。

24，DB的特性和隔離級別

4大特性：原子性，一致性，分離性，持久性

隔離級別：

讀提交：寫事務禁止讀

讀未提交：寫事務允許讀

可重復讀：寫事務禁止讀事務，讀禁止寫

序列化：全部禁止

詳細說明：讀提交1個事務開始寫則全部禁止其他事務訪問該行。讀未提交1個事務開始寫則不允許其他事務同時寫，但可以讀。可重復讀 讀事務會禁止寫事務，寫事物則禁止其他任何事務。序列化性能最低，全部禁止，串行執行。 MYSQL默認的是可重復讀。

25，帖子服務、元數據服務、帖子搜索服務，提供索引數據存儲，tid和uid查詢直接從帖子服務從元數據返回，其他檢索查詢有帖子搜索服務從索引數據檢索并返回，帖子服務增刪改查用MQ同步到帖子搜索服務，搜索服務修改索引的數據（索引樹，倒排表），索引表t_mapping（tid，uid）。

300億數據在全量索引庫中，數百萬一天內修改過的數據在一天庫中，50萬小時內修改過的數據在小時庫中，在update請求時，只會操作最低級別的索引例如小時庫。小時庫，1小時合并一次，合并到天庫，天庫一天合并1次，合并到全量庫中。

26，講一下NIO和網絡傳輸

NIO Reactor反應器模式，例如汽車是乘客訪問的實體reactor，乘客上車后到售票員處Acceptor登記，之后乘客便可休息睡覺了，到達乘客目的地后，售票員Aceptor將其喚醒即可。持久TCP長鏈接每個client和server之間有存在一個持久連接，當CCU（用戶并發數量）上升，阻塞server無法為每個連接運行1個線程，自己開發1個二進制協議，將message壓縮至3-6倍，傳輸雙向且消息頻率高，假設server鏈接了2000個client，每個client平均每分鐘傳輸1-10個message，1個messaged的大小為幾百字節/幾千字節，而server也要向client廣播其他玩家的當前信息，需要高速處理消息的能力。Buffer，網絡字節存放傳輸的地方，從channel中讀寫，從buffer作為中間存儲格式，channel是網絡連接與buffer間數據通道，像之前的socket的stream。

27，緩存擊透

預加載；

加載DB時同步，其他則等待；

DB端做SQL合并，Queue合并排隊處理；

部分緩存設置為永不過期；

先清除緩存，讀取數據時候則等待500ms，500ms緩存應該已經加載完成；

采用雙key緩存，A1為原始緩存，A2為拷貝緩存；

如果DB為空null則g給redis設置1個NFC空nei容。

28，Dubbo源碼使用了哪些設計模式

A，工廠模式，ExtenstionLoader.getExtenstionLoader(Protocol.class).getAdaptiveExtenstion()

B，裝飾器模式+責任鏈，以provider的調用鏈為例，具體調用鏈代碼是在protocolFilterWrapper的buildInvokeChain完成的,將注解中含有group=provider的Filter實現，調用順序為EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter -> ExceptionFilter -> TimeoutFilter -> MonitorFilter -> TraceFilter。裝飾器模式和責任鏈混合使用，Echo是回聲測試請求，ClassLoaderFilter則只是在其主功能上添加了功能。

C，觀察者模式，provider啟動時需要與注冊中心交互，先注冊自己的服務，再訂閱自己的服務，訂閱時采用了觀察者模式，注冊中心每5s定時檢查是否有服務更新，有更新則向服務提供者發送1個notify消息后即可運行NotifyListener的notity方法，執行監聽器方法。

D，動態代理模式。 ?擴展JDK的ExtensionLoaderdeAdaptive實現，根據調用階段動態參數決定調用哪個類，生成代理類的代碼是ExtensionLoader的createAdaptiveExtenstionClassLoader方法。

29，平衡二叉樹，左右高度之差不超過1，Add/delete可能造成高度>1，此時要旋轉，維持平衡狀態，避免二叉樹退化為鏈表，讓Add/Delete時間復雜度但控制在O(log2N)，旋轉算法2個方法，1是求樹的高度，2是求2個高度最大值，1個空樹高度為-1，只有1個根節點的樹的高度為0，以后每一層+1，平衡樹任意節點最多有2個兒子，因此高度不平衡時，此節點的2棵子樹高度差為2。例如單旋轉，雙旋轉，插入等。

紅黑樹放棄完全平衡，追求大致平衡，保證每次插入最多要3次旋轉就能平衡。

30，多線程同步鎖

A，RentrantLock，可重入的互斥鎖，可中斷可限時，公平鎖，必須在finally釋放鎖，而synchronize由JVM釋放。可重入但是要重復退出，普通的lock()不能響應中斷，lock.lockInterruptbly()可響應中斷，可以限時tryLock()，超時返回false，不會永久等待構成死鎖。

B，Confition條件變量，signal喚醒其中1個在等待的線程，signalall喚醒所有在等待的線程await()等待并釋放鎖，與lock結合使用。

C，semaphore信號量，多個線程比（額度=10）進入臨界區，其他則阻塞在臨界區外。

D，ReadWriteLock，讀讀不互斥，讀寫互斥，寫寫互斥。

E，CountDownLantch倒數計時器，countdown()和await()

F，CyCliBarrier

G，LockSupport，方法park和unpark

31，棧溢出的原因

是否遞歸的調用；大量循環；全局變量是否過多；數組，List，Map數據是否過大；用DDMS工具檢查地方。

內存溢出的原因

過多使用了static；static最好只用int和string等基本類型；大量的遞歸或者死循環；大數據項的查詢，如返回表的所有記錄，應該采用分頁查詢。檢查是否有數組、List、map中存放的是對象的引用而不是對象，這些引用會讓對應對象不能被釋放。

棧過大會導致內存占用過多，頻繁頁交換阻礙效率。

32，說一下http/2

Http/2采用二進制格式而不是文本

Http/2是完全多路復用的，而非有序并阻塞的。

Http/2使用報頭壓縮

Http/2讓服務器可以將響應主動推送到客戶端緩存中。

33，說一下內存泄露

A，HashMap,vector等容易（靜態集合類）， 和應用程序生命周期一樣，所引用的所有對象Object也不能釋放。

B，當集合類里面的對象屬性被修改后，再調用remove()不起作用，hashcode值發生了改變

C，其對象add監聽器，但是往往釋放對象時忘記去刪除這些監聽器

D，各種連接記得關閉

E，內部類的引用

F，調用其他模塊，對象作用參數

G，單例模式，持有外部對象引用無法收回。

內存泄露例子

Vector<String> A = new?Vector<String>();

for(int i = 0; i < 100; i++){

Object o = new Object ();

A.add(o);

o = null;

}

?........

內存溢出的例子

StringBuffer b = new?StringBuffer ();

for(int i =0; i < 100; i++){

for(int j =0; i < 100; j++){

b.append(*);

}

}

34，SpirngMVC的生命周期 和 SpringBean的生命周期

SpirngMVC的生命周期 ：

A，DispatcherSerlvet（前端控制器）

B，-》 HandlerMapping（處理器映射器），根據xml注解查找對應的Hander -》 返回Handler

C，-》處理器適配器去執行Handler

D，-》Handler執行完成后給處理器適配器返回ModelAndView

E，-》前端控制器請求視圖解析器去執行視圖解析，根據邏輯視圖名解析成真正的視圖JSP，向前端控制器返回view

F，-》前端控制器進行視圖渲染，將模型數據放到request-》返回給用戶

SpringBean的生命周期：

Instance實例化-》設置屬性值-》調用BeanNameAware的setBeanName方法-》調用BeanPostProsessor的預初始化方法-》調用InitializationBean的afterPropertiesSet()的方法-》調用定制的初始化方法callCustom的init-method-》調用BeanPostProsessor的后初始化方法-》Bean可以使用了 -》 容器關閉-》 調用DisposableBean的destroy方法-》調用定制的銷毀方法CallCustom的destroy-method。

35，AQS，抽象隊列同步器

AQS定義2種資源共享方式：獨占與share共享

獨占：只能有1個線程運行

share共享：多個線程可以同p執行如samphore/countdownlanch

AQS負責獲取共享state的入隊和/喚醒出隊等，AQS在頂層已經實現好了，AQS有幾種方法：acquire()是獨占模式下線程共享資源的頂層入口，如獲取到資源，線程直接返回，否則進入等待隊列，直到獲取到資源為止。tryAcquire()將線程加入等待隊列的尾部，并標志為獨占。acquireQueued()使線程在等待隊列中獲取資源，一直到獲取資源后不返回，如果過程被中斷也返回true，否則false。

線程在等待過程中被中斷是不響應的，獲取資源才補上中斷。將線程添加到隊列尾部用了CAS自旋（死循環直到成功），類似于AutomicInteger的CAS自旋volatile變量。

start->tryAcquire -> 入隊 -> 找安全點 -> park等待狀態 -> 當前節點成對頭 -> End

36，單例模式的7種寫法

懶漢2種，枚舉，餓漢2種，靜態內部類，雙重校驗鎖（推薦）。

37，lucence倒排索引

三個文件：字典文件，頻率文件，位置文件。詞典文件不僅保存有每個關鍵詞，還保留了指向頻率文件和位置文件的指針，通過指針可以找到該關鍵字的頻率信息和位置信息。

field的概念，用于表達信息所在位置（如標題中，文章中，url中），在建索引中，該field信息也記錄在詞典文件中，每個關鍵詞都有一個field信息(因為每個關鍵字一定屬于一個或多個field)。

關鍵字是按字符順序排列的（lucene沒有使用B樹結構），因此lucene可以用二元搜索算法快速定位關鍵詞。

假設要查詢單詞 “live”，lucene先對詞典二元查找、找到該詞，通過指向頻率文件的指針讀出所有文章號，然后返回結果。詞典通常非常小，因而，整個過程的時間是毫秒級的。 　　

對詞典文件中的關鍵詞進行了壓縮，關鍵詞壓縮為<前綴長度，后綴>，例如：當前詞為“阿拉伯語”，上一個詞為“阿拉伯”，那么“阿拉伯語”壓縮為<3，語>。對數字的壓縮，數字只保存與上一個值的差值。

38，ZooKeeper分布式高可用

ZooKeeper 運行期間，集群中至少有過半的機器保存了最新數據。集群超過半數的機器能夠正常工作，集群就能夠對外提供服務。

zookeeper可以選出N臺機器作主機，它可以實現M:N的備份；keepalive只能選出1臺機器作主機，所以keepalive只能實現M:1的備份。

通常有以下兩種部署方案：雙機房部署（一個穩定性更好、設備更可靠的機房，這個機房就是主要機房，而另外一個機房則更加廉價一些，例如，對于一個由 7 臺機器組成的 ZooKeeper 集群，通常在主要機房中部署 4 臺機器，剩下的 3 臺機器部署到另外一個機房中）；三機房部署（無論哪個機房發生了故障，剩下兩個機房的機器數量都超過半數。在三個機房中都部署若干個機器來組成一個 ZooKeeper 集群。假設機器總數為 N，各機房機器數：N1 = (N-1)/2?，N2=1~(N-N1)/2?，N3 = N - N1 - N2?）。

水平擴容就是向集群中添加更多機器，Zookeeper2種方式（不完美），一種是集群整體重啟，另外一種是逐臺進行服務器的重啟。
?

39，如何將數據分布在redis第幾個庫？

答：redis 本身支持16個數據庫，通過 數據庫id 設置，默認為0。
例如jedis客戶端設置。一：JedisPool(org.apache.commons.pool.impl.GenericObjectPool.Config poolConfig, String host, int port, int timeout, String password, int database);
第一種通過指定構造函數database字段選擇庫，不設置則默認0庫。二：jedis.select(index);調用jedis的select方法指定。

40，類加載器的雙親委派加載機制？

答：當一個類收到了類加載請求，他首先不會嘗試自己去加載這個類，而是把這個請求委派給父類去完成，每一個層次類加載器都是如此，因此所有的加載請求都應該傳送到啟動類加載其中，只有當父類加載器反饋自己無法完成這個請求的時候（在它的加載路徑下沒有找到所需加載的Class），子類加載器才會嘗試自己去加載。

41，kafka高性能的原因？

答：

A，Broker NIO異步消息處理，實現了IO線程與業務線程分離；

B，磁盤順序寫；

C， 零拷貝（跳過用戶緩沖區的拷貝，建立一個磁盤空間和內存的直接映射，數據不再復制到用戶態緩沖區）；

D，分區/分段（每次文件操作都是對一個小文件的操作，非常輕便，同時也增加了并行處理能力）；

F，批量發送 (可以指定緩存的消息達到某個量的時候就發出去，或者緩存了固定的時間后就發送出去，大大減少服務端的I/O次數)

E，數據壓縮

42，冪等的處理方式？

答：一、查詢與刪除操作是天然冪等

二、唯一索引，防止新增臟數據

三、token機制，防止頁面重復提交

四、悲觀鎖 ?for update

五、樂觀鎖（通過版本號/時間戳實現，?通過條件限制where avai_amount-#subAmount# >= 0）

六、分布式鎖

七、狀態機冪等（如果狀態機已經處于下一個狀態，這時候來了一個上一個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。）

八、select + insert（并發不高的后臺系統，或者一些任務JOB，為了支持冪等，支持重復執行）

43，HTTPS工作流程？
a、客戶端發送自己支持的加密規則給服務器，代表告訴服務器要進行連接了
b、服務器從中選出一套加密算法和hash算法以及自己的身份信息(地址等)以證書的形式發送給瀏覽器，證書中包含服務器信息，加密公鑰，證書的辦法機構
c、客戶端收到網站的證書之后要做下面的事情：?
? ? ? ? c1、驗證證書的合法性
? ? ? ? c2、如果驗證通過證書，瀏覽器會生成一串隨機數作為密鑰K，并用證書中的公鑰進行加密
? ? ? ? c3、用約定好的hash算法計算握手消息，然后用生成的密鑰K進行加密，然后一起發送給服務器
d、服務器接收到客戶端傳送來的信息，要求下面的事情：?
? ? ? ?d1、用私鑰解析出密碼，用密碼解析握手消息，驗證hash值是否和瀏覽器發來的一致
? ? ? ?d2、使用密鑰加密消息，回送
如果計算法hash值一致，握手成功
?

44，RabbitMQ消息堆積怎么處理？

答：

• 增加消費者的處理能力(例如優化代碼)，或減少發布頻率
• 單純升級硬件不是辦法，只能起到一時的作用
• 考慮使用隊列最大長度限制，RabbitMQ 3.1支持
• 給消息設置年齡，超時就丟棄
• 默認情況下，rabbitmq消費者為單線程串行消費，設置并發消費兩個關鍵屬性concurrentConsumers和prefetchCount，concurrentConsumers設置的是對每個listener在初始化的時候設置的并發消費者的個數，prefetchCount是每次一次性從broker里面取的待消費的消息的個數
• 建立新的queue，消費者同時訂閱新舊queue
• 生產者端緩存數據，在mq被消費完后再發送到mq
• 打破發送循環條件，設置合適的qos值，當qos值被用光，而新的ack沒有被mq接收時，就可以跳出發送循環，去接收新的消息；消費者主動block接收進程，消費者感受到接收消息過快時主動block，利用block和unblock方法調節接收速率，當接收線程被block時，跳出發送循環。
• 新建一個topic，partition是原來的10倍；然后寫一個臨時的分發數據的consumer程序，這個程序部署上去消費積壓的數據，消費之后不做耗時的處理，直接均勻輪詢寫入臨時建立好的10倍數量的queue；接著臨時征用10倍的機器來部署consumer，每一批consumer消費一個臨時queue的數據；等快速消費完積壓數據之后，得恢復原先部署架構，重新用原先的consumer機器來消費消息；

45，RabbitMQ的消息丟失解決方案？

答：

• 消息持久化：Exchange 設置持久化：durable:true；Queue 設置持久化；Message持久化發送。
• ACK確認機制：消息發送確認；消息接收確認。

46，負載均衡算法？

常見6種負載均衡算法：輪詢，隨機，源地址哈希，加權輪詢，加權隨機，最小連接數。

nginx5種負載均衡算法：輪詢，weight，ip_hash，fair（響應時間），url_hash

dubbo負載均衡算法：隨機，輪詢，最少活躍調用數，一致性Hash

47，JVM內存區域劃分？

答：

• 堆：Java中的堆是用來存儲對象本身的以及數組（當然，數組引用是存放在Java棧中的），是Java垃圾收集器管理的主要區域。堆是被所有線程共享的，在JVM中只有一個堆。
• 虛擬機棧：虛擬機棧中存放的是一個個的棧幀，每個棧幀對應一個被調用的方法，在棧幀中包括局部變量表、操作數棧、指向當前方法所屬的類的運行時常量池的引用、方法返回地址和一些額外的附加信息。當線程執行一個方法時，就會隨之創建一個對應的棧幀，并將建立的棧幀壓棧。當方法執行完畢之后，便會將棧幀出棧。
• 本地方法棧：本地方法棧則是為執行本地方法（Native Method）服務的，在HotSopt虛擬機中直接就把本地方法棧和Java棧合二為一
• 方法區：方法區與堆一樣，是被線程共享的區域。方法區存儲了類的信息（包括類的名稱、方法信息、字段信息）、靜態變量、常量以及編譯器編譯后的代碼等。在方法區中有一個非常重要的部分就是運行時常量池，它是每一個類或接口的常量池的運行時表示形式，在類和接口被加載到JVM后，對應的運行時常量池就被創建出來。當然并非Class文件常量池中的內容才能進入運行時常量池，在運行期間也可將新的常量放入運行時常量池中，比如String的intern方法。當方法區無法滿足內存分配需求時，則拋出OutOfMemoryError異常。在HotSpot虛擬機中，用永久代來實現方法區，將GC分代收集擴展至方法區，但是這樣容易遇到內存溢出的問題。JDK1.7中，已經把放在永久代的字符串常量池移到堆中。JDK1.8撤銷永久代，引入元空間。
• 程序計數器（線程私有）：是當前線程所執行的字節碼的行號指示器，每條線程都要有一個獨立的程序計數器，這類內存也稱為“線程私有”的內存。正在執行java方法的話，計數器記錄的是虛擬機字節碼指令的地址（當前指令的地址）。如果還是Native方法，則為空。
• 直接內存：在JDK1.4中新加入的NOI類，引入了一種基于通道與緩沖區的I/O方式，它可以使用Native函數直接分配堆外內存，然后通過一個存儲在Java堆中的DirectByteBuffer對象作為這塊內存的引用進行操作。

48，jvm YGC和FGC發生的具體場景？

答：

正在處理的實現事務功能，下次自動回滾。

隊列實現持久化儲存，下次啟動自動載入。

添加標志位，未處理 0，處理中 1，已處理 2。每次啟動的時候，把所有狀態為 1 的，置為 0。

關鍵性的應用就給電腦配個 UPS。

?

YGC ：對新生代堆進行gc。頻率比較高，因為大部分對象的存活壽命較短，在新生代里被回收。性能耗費較小。
FGC ：全堆范圍的gc。默認堆空間使用到達80%(可調整)的時候會觸發fgc。以我們生產環境為例，一般比較少會觸發fgc，有時10天或一周左右會有一次。

YGC發生場景：edn空間不足
FGC發生場景：old空間不足，perm空間不足，調用方法System.gc() ，ygc時的悲觀策略, dump live的內存信息時(jmap –dump:live)

49，一個線程池正在處理服務如果忽然斷電該怎么辦？

答：

隊列實現持久化儲存，下次啟動自動載入。
但是實際需要看情況，大體思路是這樣。
添加標志位，未處理 0，處理中 1，已處理 2。每次啟動的時候，把所有狀態為 1 的，置為 0。或者定時器處理
關鍵性的應用就給電腦配個 UPS。

50，SpringBoot的優點？

答：

快速構建項目，極大的提高了開發、部署效率。
對主流開發框架的無配置集成。
項目可獨立運行，無須外部依賴Servlet容器。
提供運行時的應用監控。

51，DoS，DDoS，DRDoS攻擊分別是什么？

答：DoS是Denial of Service的簡寫就是拒絕服務。

DDoS就是Distributed Denial of Service的簡寫就是分布式拒絕服務。

DRDoS就是Distributed Reflection Denial of Service的簡寫,分布反射式拒絕服務。

DoS、DDos以及DRDoS攻擊手段和防范措施

52，服務限流的方式？

答：

• 漏桶：水(請求)先進入到漏桶里,漏桶以一定的速度出水(接口有響應速率),當水流入速度過大會直接溢出(訪問頻率超過接口響應速率),然后就拒絕請求。
• 令牌桶算法：系統會按恒定1/QPS時間間隔(如果QPS=100,則間隔是10ms)往桶里加入Token，如果桶已經滿了就不再加了.新請求來臨時,會各自拿走一個Token,如果沒有Token就拒絕服務。
• 基于redis實現的限流：假設每分鐘訪問次數不能超過10次，在Redis中創建一個鍵，過期60秒，對此服務接口的訪問就把鍵值加1，在60秒內增加到10的時候，禁止訪問服務接口。
• 計數器，滑動窗口

53，Quartz實現原理?

答：A、scheduler是一個計劃調度器容器（總部），容器里面可以盛放眾多的JobDetail和trigger，當容器啟動后，里面的每個JobDetail都會根據trigger按部就班自動去執行。
B、JobDetail是一個可執行的工作，它本身可能是有狀態的。
C、Trigger代表一個調度參數的配置，什么時候去調。
D、當JobDetail和Trigger在scheduler容器上注冊后，形成了裝配好的作業（JobDetail和Trigger所組成的一對兒），就可以伴隨容器啟動而調度執行了。
E、scheduler是個容器，容器中有一個線程池，用來并行調度執行每個作業，這樣可以提高容器效率。

54，數據庫的鎖？

答：行鎖（共享鎖和排他鎖），表鎖，頁級鎖，頁級鎖，意向鎖，讀鎖，寫鎖，悲觀鎖，樂觀鎖等

55，簡述ThreadPoolExecutor內部工作原理？

答：

先查看當前運行狀態，如果不是RUNNING 狀態會拒絕執行任務，如果是RUNNING狀態，就會查看當前運行的線程數量，如果小于核心線程數，會創建新的線程來執行這個任務，如果不小于核心線程，會將這個任務放到阻塞隊列去等代執行，直到上一個任務執行完再來執行這個任務。如果失敗會創建一個非核心線程來執行這個任務如果當前線程數大于最大線程數，會直接拒絕該任務。

56，聚集索引和非聚集索引的區別？

答：

聚集索引：
索引中鍵值的邏輯順序決定了表中相應行的物理順序（索引中的數據物理存放地址和索引的順序是一致的），可以這么理解：只要是索引是連續的，那么數據在存儲介質上的存儲位置也是連續的。
比方說：想要到字典上查找一個字，我們可以根據字典前面的拼音找到該字，注意拼音的排列時有順序的。
聚集索引就像我們根據拼音的順序查字典一樣，可以大大的提高效率。在經常搜索一定范圍的值時，通過索引找到第一條數據，根據物理地址連續存儲的特點，然后檢索相鄰的數據，直到到達條件截至項。
非聚集索引
索引的邏輯順序與磁盤上的物理存儲順序不同。非聚集索引的鍵值在邏輯上也是連續的，但是表中的數據在存儲介質上的物理順序是不一致的，即記錄的邏輯順序和實際存儲的物理順序沒有任何聯系。索引的記錄節點有一個數據指針指向真正的數據存儲位置。
總結如下：
如果一個主鍵被定義了，那么這個主鍵就是作為聚集索引
如果沒有主鍵被定義，那么該表的第一個唯一非空索引被作為聚集索引
如果沒有主鍵也沒有合適的唯一索引，那么innodb內部會生成一個隱藏的主鍵作為聚集索引，這個隱藏的主鍵是一個6個字節的列，改列的值會隨著數據的插入自增。
InnoDB引擎會為每張表都加一個聚集索引，而聚集索引指向的的數據又是以物理磁盤順序來存儲的，自增的主鍵會把數據自動向后插入，避免了插入過程中的聚集索引排序問題。如果對聚集索引進行排序，這會帶來磁盤IO性能損耗是非常大的。

57，java并發包下有哪些類？

答：ConcurrentHashMap，ConcurrentSkipListMap，ConcurrentNavigableMap

CopyOnWriteArrayList

BlockingQueue，BlockingDeque （ArrayBlockingQueue，LinkedBlockingDeque，LinkedBlockingQueue，DelayQueue，PriorityBlockingQueue，SynchronousQueue）

ConcurrentLinkedDeque，ConcurrentLinkedQueue，TransferQueue，LinkedTransferQueue

CopyOnWriteArraySet，ConcurrentSkipListSet

CyclicBarrier，CountDownLatch

Lock（ReetrantLock，ReetrantReadWriteLock）

Atomic包

58，threadlocal為什么會出現oom？

答：ThreadLocal里面使用了一個存在弱引用的map, map的類型是ThreadLocal.ThreadLocalMap. Map中的key為一個threadlocal實例。這個Map的確使用了弱引用，不過弱引用只是針對key。每個key都弱引用指向threadlocal。 當把threadlocal實例置為null以后，沒有任何強引用指向threadlocal實例，所以threadlocal將會被gc回收。?
但是，我們的value卻不能回收，而這塊value永遠不會被訪問到了，所以存在著內存泄露。因為存在一條從current thread連接過來的強引用。只有當前thread結束以后，current thread就不會存在棧中，強引用斷開，Current Thread、Map value將全部被GC回收。最好的做法是將調用threadlocal的remove方法。

在ThreadLocal的get(),set(),remove()的時候都會清除線程ThreadLocalMap里所有key為null的value，但是這些被動的預防措施并不能保證不會內存泄漏：

（1）使用static的ThreadLocal，延長了ThreadLocal的生命周期，可能導致內存泄漏。?
（2）分配使用了ThreadLocal又不再調用get(),set(),remove()方法，那么就會導致內存泄漏，因為這塊內存一直存在。

59，mysql數據庫鎖表怎么解決？

答：查詢鎖表信息
當前運行的所有事務
select * from information_schema.innodb_trx
當前出現的鎖
select * from information_schema.innodb_locks
鎖等待的對應關系
select * from information_schema.innodb_lock_waits ?

通過 select * from information_schema.innodb_trx 查詢 trx_mysql_thread_id然后執行 kill 線程ID
KILL ? 8807;//后面的數字即時進程的ID

60，java 判斷對象是否是某個類的類型方法？

• instanceof 運算符是用來在運行時指出對象是否是特定類的一個實例。instanceof通過返回一個布爾值來指出，這個對象是否是這個特定類或者是它的子類的一個實例。
• getClass判斷，如o.getClass().equals(ClassA.class)。（使用instanceof來判斷一個對象是不是屬于某個類，但是有時候這個類是繼承于一個父類的，所以，不能嚴格判斷出是不是自己的類，而不是自己的父類。）?

61，Spring+MyBatis實現讀寫分離簡述？

答：

• 方案一：通過MyBatis配置文件創建讀寫分離兩個DataSource，每個SqlSessionFactoryBean對象的mapperLocations屬性制定兩個讀寫數據源的配置文件。將所有讀的操作配置在讀文件中，所有寫的操作配置在寫文件中。
• 方案二：通過Spring AOP在業務層實現讀寫分離，在DAO層調用前定義切面，利用Spring的AbstractRoutingDataSource解決多數據源的問題，實現動態選擇數據源
• 方案三：通過Mybatis的Plugin在業務層實現數據庫讀寫分離，在MyBatis創建Statement對象前通過攔截器選擇真正的數據源，在攔截器中根據方法名稱不同（select、update、insert、delete）選擇數據源。
• 方案四：通過spring的AbstractRoutingDataSource和mybatis Plugin攔截器實現非常友好的讀寫分離，原有代碼不需要任何改變。推薦第四種方案

62，紅黑樹的特點？

答：（1）每個節點或者是黑色，或者是紅色。
（2）根節點是黑色。
（3）每個葉子節點（NIL）是黑色。?[注意：這里葉子節點，是指為空(NIL或NULL)的葉子節點！]
（4）如果一個節點是紅色的，則它的子節點必須是黑色的。
（5）從一個節點到該節點的子孫節點的所有路徑上包含相同數目的黑節點。[這里指到葉子節點的路徑]

63，kafka消息會不會丟失？

答：Kafka消息發送分同步(sync)、異步(async)兩種方式。默認是使用同步方式，可通過producer.type屬性進行配置；Kafka保證消息被安全生產，有三個選項分別是0,1,-1。
通過request.required.acks屬性進行配置：
0代表：不進行消息接收是否成功的確認(默認值)；
1代表：當Leader副本接收成功后，返回接收成功確認信息；
-1代表：當Leader和Follower副本都接收成功后，返回接收成功確認信息；

• 網絡異常
  acks設置為0時，不和Kafka集群進行消息接受確認，當網絡發生異常等情況時，存在消息丟失的可能；
• 客戶端異常
  異步發送時，消息并沒有直接發送至Kafka集群，而是在Client端按一定規則緩存并批量發送。在這期間，如果客戶端發生死機等情況，都會導致消息的丟失；
• 緩沖區滿了
  異步發送時，Client端緩存的消息超出了緩沖池的大小，也存在消息丟失的可能；
• Leader副本異常
  acks設置為1時，Leader副本接收成功，Kafka集群就返回成功確認信息，而Follower副本可能還在同步。這時Leader副本突然出現異常，新Leader副本(原Follower副本)未能和其保持一致，就會出現消息丟失的情況；

以上就是消息丟失的幾種情況，在日常應用中，我們需要結合自身的應用場景來選擇不同的配置。
想要更高的吞吐量就設置：異步、ack=0；想要不丟失消息數據就選：同步、ack=-1策略

64，kafka的leader副本選舉？

答：如果某個分區patition的Leader掛了,那么其它跟隨者將會進行選舉產生一個新的leader,之后所有的讀寫就會轉移到這個新的Leader上,在kafka中,其不是采用常見的多數選舉的方式進行副本的Leader選舉,而是會在Zookeeper上針對每個Topic維護一個稱為ISR（in-sync replica，已同步的副本）的集合,顯然還有一些副本沒有來得及同步。只有這個ISR列表里面的才有資格成為leader(先使用ISR里面的第一個，如果不行依次類推，因為ISR里面的是同步副本，消息是最完整且各個節點都是一樣的)。
??通過ISR,kafka需要的冗余度較低，可以容忍的失敗數比較高。假設某個topic有f+1個副本，kafka可以容忍f個不可用,當然,如果全部ISR里面的副本都不可用,也可以選擇其他可用的副本,只是存在數據的不一致。

65，kafka消息的檢索？

答：其實很簡單主要是用二分查找算法,比如我們要查找一條offest=10000的文件,kafka首先會在對應分區下的log文件里采用二分查看定位到某個記錄該offest
=10000這條消息的log,然后從相應的index文件定位其偏移量,然后拿著偏移量到log里面直接獲取。這樣就完成了一個消息的檢索過程。

66，RabbitMQ 集群方式？

答：

1）普通集群：

以兩個節點（rabbit01、rabbit02）為例來進行說明。
????rabbit01和rabbit02兩個節點僅有相同的元數據，即隊列的結構，但消息實體只存在于其中一個節點rabbit01（或者rabbit02）中。
????當消息進入rabbit01節點的Queue后，consumer從rabbit02節點消費時，RabbitMQ會臨時在rabbit01、rabbit02間進行消息傳輸，把A中的消息實體取出并經過B發送給consumer。所以consumer應盡量連接每一個節點，從中取消息。即對于同一個邏輯隊列，要在多個節點建立物理Queue。否則無論consumer連rabbit01或rabbit02，出口總在rabbit01，會產生瓶頸。當rabbit01節點故障后，rabbit02節點無法取到rabbit01節點中還未消費的消息實體。如果做了消息持久化，那么得等rabbit01節點恢復，然后才可被消費；如果沒有持久化的話，就會產生消息丟失的現象。

2）鏡像集群：

?在普通集群的基礎上，把需要的隊列做成鏡像隊列，消息實體會主動在鏡像節點間同步，而不是在客戶端取數據時臨時拉取，也就是說多少節點消息就會備份多少份。該模式帶來的副作用也很明顯，除了降低系統性能外，如果鏡像隊列數量過多，加之大量的消息進入，集群內部的網絡帶寬將會被這種同步通訊大大消耗掉。所以在對可靠性要求較高的場合中適用
? ? 由于鏡像隊列之間消息自動同步，且內部有選舉master機制，即使master節點宕機也不會影響整個集群的使用，達到去中心化的目的，從而有效的防止消息丟失及服務不可用等問題

67，ElasticSearch如何解決深度分頁的問題？

答：使用scroll（有狀態）和search after（無狀態）的游標方式。

68，java代碼優化(一)

答：盡量指定類、方法的final修飾符。
盡量重用對象。
盡可能使用局部變量。
及時關閉流。
盡量減少對變量的重復計算。
盡量采用懶加載的策略，即在需要的時候才創建。
慎用異常。
不要在循環中使用try...catch...，應該把其放在最外層。
如果能估計到待添加的內容長度，為底層以數組方式實現的集合、工具類指定初始長度。
當復制大量數據時，使用System.arraycopy()命令。
乘法和除法使用移位操作。
循環內不要不斷創建對象引用。
基于效率和類型檢查的考慮，應該盡可能使用array，無法確定數組大小時才使用ArrayList。
盡量使用HashMap、ArrayList、StringBuilder，除非線程安全需要，否則不推薦使用Hashtable、Vector、StringBuffer，后三者由于使用同步機制而導致了性能開銷。
不要將數組聲明為public static final。

69，java代碼優化(二)

答：盡量在合適的場合使用單例。
盡量避免隨意使用靜態變量。
及時清除不再需要的會話。
實現RandomAccess接口的集合比如ArrayList，應當使用最普通的for循環而不是foreach循環來遍歷
使用同步代碼塊替代同步方法。
將常量聲明為static final，并以大寫命名。
不要創建一些不使用的對象，不要導入一些不使用的類。
程序運行過程中避免使用反射。
使用數據庫連接池和線程池。
使用帶緩沖的輸入輸出流進行IO操作。
順序插入和隨機訪問比較多的場景使用ArrayList，元素刪除和中間插入比較多的場景使用LinkedList。
不要讓public方法中有太多的形參。
字符串變量和字符串常量equals的時候將字符串常量寫在前面。
請知道，在java中if (i == 1)和if (1 == i)是沒有區別的，但從閱讀習慣上講，建議使用前者。
不要對數組使用toString()方法。
不要對超出范圍的基本數據類型做向下強制轉型。

70，java代碼優化(三)

答:公用的集合類中不使用的數據一定要及時remove掉。
把一個基本數據類型轉為字符串，基本數據類型.toString()是最快的方式、String.valueOf(數據)次之、數據+""最慢
使用最有效率的方式去遍歷Map。
對資源的close()建議分開操作。
對于ThreadLocal使用前或者使用后一定要先remove。
切記以常量定義的方式替代魔鬼數字，魔鬼數字的存在將極大地降低代碼可讀性，字符串常量是否使用常量定義可以視情況而定。
long或者Long初始賦值時，使用大寫的L而不是小寫的l，因為字母l極易與數字1混淆，這個點非常細節，值得注意。
所有重寫的方法必須保留@Override注解。
推薦使用JDK7中新引入的Objects工具類來進行對象的equals比較，直接a.equals(b)，有空指針異常的風險。
循環體內不要使用"+"進行字符串拼接，而直接使用StringBuilder不斷append。
不捕獲Java類庫中定義的繼承自RuntimeException的運行時異常類。
避免Random實例被多線程使用，雖然共享該實例是線程安全的，但會因競爭同一seed導致的性能下降，JDK7之后，可以使用ThreadLocalRandom來獲取隨機數。
靜態類、單例類、工廠類將它們的構造函數置為private。

71，單點登錄原理與簡單實現？

答：相比于單系統登錄，sso需要一個獨立的認證中心，只有認證中心能接受用戶的用戶名密碼等安全信息，其他系統不提供登錄入口，只接受認證中心的間接授權。間接授權通過令牌實現，sso認證中心驗證用戶的用戶名密碼沒問題，創建授權令牌，在接下來的跳轉過程中，授權令牌作為參數發送給各個子系統，子系統拿到令牌，即得到了授權，可以借此創建局部會話，局部會話登錄方式與單系統的登錄方式相同。這個過程，也就是單點登錄的原理，用下圖說明

單點登錄自然也要單點注銷，在一個子系統中注銷，所有子系統的會話都將被銷毀，用下面的圖來說明

72，MQ做數據同步也會造成不一致，又需要引入監控，實時計算2個集群的數據同步，做一致性同步。大部分來說，同步es和solr不要在代碼中去同步，同步失敗無法保證事務，而且業務耦合。可以使用Databug和cancel等工具去做代碼解耦，MQ支持重試，存儲失敗后拋出異常下次再處理。數據做異構，對外服務時任意拼裝，MYSQL在半同步復制上做了一些優化，保證了一致性，引入了諸如paxos等主流算法保證強一致性問題。
當DB（監聽從庫），binlog有變化，cancel監聽到時候解析過濾發送MQ（表名字，主鍵等）到變化的實時從庫中查詢數據同步到ES聚合表，MQ可以重試，系統解耦。事務log挖掘縣城會對DB的事務log監聽，并把這些事件發布到消息代理。

73，分布式服務調用可以實現跟蹤系統，可以在業務日志中添加調用鏈ID，各個環節RPC均添加調用時延,QPS等。

非業務組件應該少加入業務代碼，服務調用采用買點，也會采用配置采樣率方式，買點即當前節點的上下文信息，包含TraceId，RPCId，開始結束時間，類型，協議，調用方IP，端口，服務名等，以及其他異常信息，報文等擴展，日志采用離線+實時的如flume結合kafka等，應按照TraceId匯總日志后按RPCId順序整理。

74，Sentinel 工作原理？

答：（1）每個 Sentinel 以每秒鐘一次的頻率向它所知的 Master，Slave 以及其他 Sentinel 實例發送一個 PING 命令；
（2）如果一個實例（instance）距離最后一次有效回復 PING 命令的時間超過 down-after-milliseconds 選項所指定的值， 則這個實例會被 Sentinel 標記為主觀下線；
（3）如果一個 Master 被標記為主觀下線，則正在監視這個 Master 的所有 Sentinel 要以每秒一次的頻率確認 Master 的確進入了主觀下線狀態；
（4）當有足夠數量的 Sentinel（大于等于配置文件指定的值）在指定的時間范圍內確認 Master 的確進入了主觀下線狀態，則 Master 會被標記為客觀下線；
（5）在一般情況下， 每個 Sentinel 會以每 10 秒一次的頻率向它已知的所有 Master，Slave 發送 INFO 命令；
當 Master 被 Sentinel 標記為客觀下線時，Sentinel 向下線的 Master 的所有 Slave 發送 INFO 命令的頻率會從 10 秒一次改為每秒一次；
（6）若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被移除；
（7）若 Master 重新向 Sentinel 的 PING 命令返回有效回復， Master 的主觀下線狀態就會被移除。

監控（ Monitoring ）： Redis Sentinel 實時監控主服務器和從服務器運行狀態；
自動故障轉移：如果一個 master 不正常運行了，哨兵可以啟動一個故障轉移進程，將一個 slave 升級成為 master，其他的 slave 被重新配置使用新的 master，并且應用程序使用 Redis 服務端通知的新地址；

75，高性能統計UV的方式？

（1）使用redis的set集合

（2）使用redis的bitmap（注意內存消耗）

76，Hbase二級索引，索引海量數據實現方案？

答：

(1) 方案1:使用開源的hbase-indexer，是借助于hbase的WAL實現，不會影響hbase性能

? ?https://blog.csdn.net/xiahoujie_90/article/details/53400044

(2)? 方案2：基于ES自己實現，利用habse的協處理器實現，會影響hbase性能

關鍵注意點：因為數據是存在Hbase中，ES充當的是索引角色，所以在創建ES的mapping時，

應指定_source為enabled:false。關閉存儲原始文檔。

https://wenku.baidu.com/view/422722fdd0f34693daef5ef7ba0d4a7303766c71.html

77，Elasticsearch分片使用優化?

答：(1)拆分集群
對于存在明顯分界線的業務，可以按照業務、地域使用不同集群，這種拆分集群的思路是非常靠譜的。對于我們的場景，已經按照地域拆分了集群，且同一地域的子業務間分界線不明顯，拆分過多的集群維護成本較高。
(2)調整滾動周期
根據保留時長調整index滾動周期是最簡單有效的思路。例如保留3天的數據按天滾動，保留31天的數據按周滾動，保留一年的數據按月滾動。合理的滾動周期，可以在存儲成本增加不大的情況下，大幅降低分片數量。
對于我們的場景，大部分數據保留31天，在按周滾動的情況下，集群的總分片數可以下降到6.5w~個。
(3)合理設置分片數和副本數
除個別子業務壓力較高外，大部分業務壓力較小，合理設置單Index的分片數效果也不錯。我們的經驗是單個分片的大小在10GB~30GB之間比較合適，對于壓力非常小的業務可以直接分配1個分片。其他用戶可結合具體場景考慮，同時注意單分片的記錄條數不要超過上限2,147,483,519。
在平衡我們的業務場景對數據可靠性的要求 及 不同副本數對存儲成本的開銷 兩個因素之后，我們選擇使用一主一從的副本策略。
目前我們集群單Index的平均分配數為3，集群的總分片數下降到3w~個。
(4)分片分配流程優化
默認情況下，ES在分配分片時會考慮分片relocation對磁盤空間的影響。在分片數較少時，這個優化處理的副作用不明顯。但隨著單機分片數量的上升，這個優化處理涉及的多層循環嵌套過程耗時愈發明顯。可通過cluster.routing.allocation.disk.include_relocations: false關閉此功能，這對磁盤均衡程度影響不明顯。
(5)預創建Index
對于單集群3w分片的場景，集中在每周某天0點創建Index，對集群的壓力還是較大，且存儲空間存在波動。考慮到集群的持續擴展能力和可靠性，我們采用預創建方式提前創建分片，并把按Index的創建時間均勻打散到每周的每一天。
(6)持續調整分片數
對于集群分片的調整，通常不是一蹴而就的。隨著業務的發展，不斷新增的子業務 或 原有子業務規模發生突變，都需要持續調整分片數量。
默認情況下，新增的子業務會有默認的分片數量，如果不足，會在測試階段及上線初期及時發現。隨著業務發展，系統會考慮Index近期的數據量、寫入速度、集群規模等因素，動態調整分片數量。

78，如何編寫高質量代碼151建議？

答：

一、Java開發中通用的方法和準則
不要在常量和變量中出現易混淆的字母;
莫讓常量蛻變成變量;
三元操作符的類型務必一致;
避免帶有變長參數的方法重載;
別讓null值和空值威脅到變長方法;
覆寫變長方法也要循規蹈矩;
警惕字增的陷阱;
不要讓舊語法困擾你;
少用靜態導入;
不要在本類中覆蓋靜態導入的變量和方法;
養成良好習慣，顯示聲明UID;
避免用序列化類在構造函數中為不變量賦值;
避免為final變量復雜賦值;
使用序列化類的私有方法巧妙解決部分屬性持久化問題;
break萬萬不可忘;
易變業務使用腳本語言編寫;
慎用動態編譯;
避免instantceof非預期結果;
斷言對決不是雞肋;
不要只替換一個類;

二、基本類型
使用偶判斷，不用奇判斷;
用整數類型處理貨幣;
不要讓類型默默轉換;
邊界，邊界，還是邊界;
不要讓四舍五入虧了一方;
提防包裝類型的null值;
謹慎包裝類型的大小比較;
優先使用整型池;
優先選擇基本類型;
不要隨便設置隨機種子;

三、類、對象及方法
在接口中不要存在實現代碼;
靜態變量一定要先聲明后賦值;
不要覆寫靜態方法;
構造函數盡量簡化;
避免在構造函數中初始化其他類;
使用構造代碼塊精煉程序;
使用靜態內部類提供封裝性;
使用匿名類的構造函數;
匿名類的構造函數很特殊;
讓多重繼承成為現實;
讓工具類不可實例化;
避免對象的淺拷貝;
推薦使用序列化實現對象的拷貝;
覆寫equals方法時不要識別不出自己;
equals應該考慮null值情景;
在equals中使用getClass進行類型判斷;
覆寫equals方法必須覆寫hashCode方法;
推薦覆寫toString方法;
使用package-info類為包服務;
不要主動進行垃圾回收;

四、字符串
推薦使用String直接量賦值;
注意方法中傳遞的參數要求;
正確使用String、StringBuffer、StringBuilder;
注意字符串的位置;
自由選擇字符串拼接方法;
推薦在復雜字符串操作中使用正則表達式;
強烈建議使用UTF編碼;
對字符串排序持一種寬容的心態;

五、數組和集合
性能考慮，數組是首選;
若有必要，使用變長數組;
警惕數組的淺拷貝;
在明確的場景下，為集合指定初始容量;
多種最值方法，適時選擇;
避開基本類型數組轉換列表陷阱;
asList方法產生的List對象不可更改;
不同的列表選擇不同的遍歷方法;
頻繁插入和刪除時使用LinkedList;
列表相等只需關心元素數據;
推薦使用subList處理局部列表;
生成子表后不要再操作原列表;
使用Comparator進行排序;
不推薦使用binarySearch對列表進行檢索;
集合中的元素必須做到compareTo和equals同步;
集合運算時使用更優雅的方式;
使用shuffle大亂列表;
減少HashMap中元素的數量;
集合中的哈希碼不要重復;
多線程使用Vector或者HashTable;
非穩定排序推薦使用List;

六、枚舉和注解
推薦使用枚舉定義常量;
使用構造函數協助描述枚舉項;
小心switch帶來的空值異常;
在switch的default代碼塊中增加AssertionError錯誤;
使用valueOf前必須進行校驗;
用枚舉實現工廠方法模式更簡潔;
枚舉項的數量限制在64個以內;
小心注解繼承;
枚舉和注解結合使用威力更大;
注意@Override不同版本的區別;

七、枚舉和注解
Java的泛型是類型擦除的;
不能初始化泛型參數和數組;
強制聲明泛型的實際類型;
不同的場景使用不同的泛型通配符;
警惕泛型是不能協變和逆變的;
建議采用的順序是List<T>、List<?>、List<Object>;
嚴格限定泛型類型采用多重界限;
數組的真實類型必須是泛型類型的子類型;
注意Class類的特殊性;
適時選擇getDeclaredXXX和getXXX;
反射訪問屬性或方法時將Accessible設置為true;
使用forName動態加載類文件;
動態加載不合適數組;
動態代理可以使代理模式更加靈活;
反射讓模板方法模式更強大;
不需要太多關注反射效率;

八、異常
提倡異常封裝;
采用異常鏈傳遞異常;
受檢異常盡可能轉化為非受檢異常;
不要在finally塊中處理返回值;
使用Throwable獲取棧信息;
異常只為異常服務;
多使用異常，把性能問題放一邊;

九、多線程和并發
不推薦覆寫start方法;
啟動線程前stop方法是不可靠的;
不使用stop方法停止線程;
線程優先級只使用三個等級;
使用線程異常處理器提升系統可靠性;
volatile不能保證數據同步;
異步運算多考慮使用Callable接口;
優先選擇線程池;
適時選擇不同的線程池來實現;
Lock與synchronized是不一樣的;
預防線程死鎖;
適當設置阻塞隊列長度;
使用CountDownLatch協調子線程;
CyclicBarrier讓多線程齊步走;

?

?

?

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的阿里java高级工程师面试100题（建议收藏）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。