2年java，螞蟻一面，卒

??? 這篇文章這麼火？把真正有價值的文章都頂下去了，汗...散了吧。

更多精彩文章。

《微服務不是所有，只是特定領域的子集》

《「分庫分表" ？選型和流程要慎重，不然會失控》

這麼多監控組件，總有一款適合你

《使用Netty，咱們到底在開發些什麼？》

《這多是最中肯的Redis規範了》

《程序員畫像，十年沉浮》

最有用系列：

《Linux生產環境上，最經常使用的一套「vim「技巧》

《Linux生產環境上，最經常使用的一套「Sed「技巧》

《Linux生產環境上，最經常使用的一套「AWK「技巧》

---

Linux五件套之類的。

《Linux之《荒島餘生》（一）準備篇》

《Linux之《荒島餘生》（二）CPU篇》

《Linux之《荒島餘生》（三）內存篇》

《Linux之《荒島餘生》（四）I/O篇》

《Linux之《荒島餘生》（五）網絡篇》

更多請關注。固然也能夠關注公衆號。

---

↓↓↓↓2019.06.11↓↓↓↓↓↓

其實我一個都沒答上來。並非由於我笨，是由於我不會。在大擾的幫助下，如今我會了，求求你再給我一個機會。

TreeSet/HashSet 區別

顧名思義，首先是結構上的不一樣

一、TreeSet背後的結構是TreeMap，也就是紅黑樹，可以實現自動排序。它經過equals方法或者compareTo方法進行內容的比較。

二、HashSet背後是HashMap，key是無序的，只能作外部排序。既然是Hash，那麼就要重寫其中對象的hashCode和equals方法

另外，還有個細微的差異能夠拿來裝b：

一、HashSet能夠接受null值，有且只有一個 二、TreeSet默認不能夠接受null值，會直接拋出空指針異常

set裏沒有重複數據，TreeSet裏連虛無都沒有。

HashMap 如何解決衝突,擴容機制

爛大街的問題，問哪答哪吧。這樣的東西就是靠背。

HashMap的內部結構實際上是數組+鏈表（java8後若是長度大於8則轉換爲紅黑樹）。HashMap初始化時，默認有16個hash槽。

存入對象時，首先，經過對象的hashCode，定位到hash槽。若是多個對象同時落入同一個槽，那麼就會使用鏈表解決本槽上的衝突。

HashMap在建立時，會有一個負載因子。每次put操做，都會檢查當前容量是否會超出閾值(initailCapacity*loadFactor)。若是超出，則擴容爲當前的兩倍。擴容後，數據須要從新散列，也就是transfer方法。

經驗：resize很是耗時，因此若是可以提早預估容量，能夠把initailCapacity提早固定下來。

ConcurrentHashMap 如何作到高併發的

簡單點說，使用了分段鎖（分離鎖）。每一把鎖用於鎖住容器中的一部分數據，減小線程間對鎖的競爭。

這道題往深裏問會死人的，篇幅有限，不囉嗦。

線程池日常怎麼用

普通的場景，使用工廠類Executors建立就能夠了。經常使用的有Single、Fixed、Cached三種。

更多時候，爲了更精細的控制，會直接對ThreadPoolExecutor類進行定製。阿里的規範也要求這麼搞（固然要舔一舔），我尤爲關心其中的阻塞隊列和飽和策略。

固然，你只有對阻塞隊列和拒絕策略熟悉才能這麼說。不然給本身挖坑就太不聰明瞭。

他們很喜歡你提到阿里規範，這讓我以爲jdk設計的很low

多個線程等待到某一節點而後統一放行有幾種實現方式?

最經典的就是CountDownLatch，主線程阻塞在await方法，每一個線程調用countDown。能夠解決一些經典的賽馬問題。

還有一個變種就是CyclicBarrier。每一個線程都阻塞在await方法，達到必定閾值集體放行。

另外還可使用一些較初級的api，好比Thread的join方法。Future的get方法等。複雜不推薦。

也能夠答sleep啊。有什麼問題麼？我用while等待一個變量也是能夠的，但我爲何要這麼作？

數據庫索引結構

B+ Tree，爲了適應緩慢的磁盤而生的一種索引結構。必須保證按照索引的最左前綴查詢。

Hash 和HashMap相似，處理衝突的方式是鏈表

pg的索引結構就多了去了。Mysql這麼少怎麼感受怪怪的？難道要我回答存儲引擎的區別？

select * from t where a=? and b>? order by c limit 0,100 如何加索引

知道這個就結論就好了=> 當order by 字段出如今where條件中時，纔會利用索引而無需排序操做。其餘狀況，order by不會出現排序操做。

按照最左原則，我能夠建立 (a,b) 的索引。

什麼是聚簇索引和非聚簇索引

一個表只能有一個聚簇索引。主索引文件和數據文件爲同一份文件，默認的InnoDB就支持聚簇索引，B+ Tree的葉子節點上的data就是數據自己。

而MyISAM就不支持聚簇索引，它的葉子結點存放的不是數據自己，而是數據存放的地址。在文件結構上，會分爲一個索引文件、一個數據文件。

對編程來講沒什麼鳥用。

瞭解 CAP 嗎?redis 裏的 CAP 是怎樣的?

• Consistency 一致性
• Availability 可用性
• Partition tolerance 分區容錯 通常，都在C、A之間進行權衡。

redis簡單主從模式側重於CP的，即對於一致性要求較高。 redis-cluster，則屬於AP類型，更增強調可用性

cap就是帽子，綠油油的那種

如何理解冪等?項目中接口的冪等是如何作的?

冪等是指屢次執行，影響相同。

好比大多數Post操做，重複提交訂單等，最終只會有一個訂單生成成功。還有一種狀況就是消息，因爲大多數MQ之保證at least once，因此消息有時會重複。

一、對於Post請求，我通常在請求成功後，強制跳轉到其餘頁面，避免刷新提交。

二、複雜的操做通常使用流水號來實現。

三、某些不帶流水號的消息，處理的時候，就要進行屢次校驗和check，甚至引入消息狀態表，來保證冪等。

就如同表白，每次表白都是被拒絕，由於我就是那個id！

解釋下樂觀鎖悲觀鎖

悲觀鎖老是假設狀況最壞，每次操做數據都認爲別人會修改，就加鎖來保證安全。後面的訪問者只能等待。數據庫中的行鎖、表鎖，java中的同步關鍵字等，都屬於悲觀鎖。

樂觀鎖正好相反，老是假設最好的狀況，不用對數據加鎖，但多了一次額外的判斷操做。好比concurrent包裏大量的CAS操做、判斷新舊版本號機制等。

悲觀鎖是老婆，有你獨佔；樂觀鎖是炮友，按預定規劃

JVM 判斷對象是否回收?

答案就是GC roots。也就是從根對象出發，沒有任何一個對象引用到它，那麼就判斷這個對象是不可達的。

一般被罵「斷子絕孫」的人，就是要被回收的root

GCROOT 有哪些?

1 、 虛擬機棧（棧幀中的本地變量表）中引用的對象。

二、 本地方法棧中JNI（即通常說的native方法）引用的對象。

三、 方法區中的靜態變量和常量引用的對象。

四、活躍線程的引用對象

因此不要讓他們過分繁殖。

反射能得到類裏面方法的名稱嗎?參數名稱呢?參數類型呢?

均可以。

java8之後，經過Parameter類獲取參數名稱。但有前提，須要加編譯開關。

javac -parameters
複製代碼

默認是關閉的，幹！

問題都偏到月球上去了

動態代理的實現方式?CgLib 和 jdk 的代理有什麼區別?

java中經過實現InvocationHandler接口來實現動態代理，而後使用Proxy將其初始化。

Cglib使用了ASM本身嗎生成框架，能夠代理普通類，但代理不了final類，而jdk的只能代理接口。

在spring裏，cglib勝出

分佈式鎖有哪些主流實現方式?redis 和 zk 鎖有什麼區別?

大致分爲兩類。

樂觀鎖： 基於版本號機制和CAS實現，與存放版本號的存儲無關。

悲觀鎖： 一、基於數據庫記錄，進入時寫數據，退出時刪記錄

二、數據庫行鎖，好比分佈式quartz，它是一把排它鎖

三、基於Redis的setnx函數（因爲大多數會設置超時，因此推薦用帶px的set原子函數）

四、基於zookeeper

區別：

redis獲取鎖是輪訓機制。鎖釋放後會有多個調用者爭搶，某些任務有可能餓死。

zk是監聽機制，有變更會接到通知。除了非公平鎖，也能夠實現公平鎖。

從優雅性來講，顯然redis勝出

ThreadLocal 做用是什麼?說下用法

ThreadLocal用來隔離數據。 ThreadLocal中存放的是與線程相關的數據，底層其實是一個map，經過線程能夠獲取存儲數據的map。

這種方式與Servlet中的Request相似。

一些須要綁定到線程的數據，好比一些線程的統計數據，就能夠放在這裏。

聽說這是一種線程同步方式，但它明顯無鎖啊。

ThreadLocal有沒有優化方式?

ThreadLocal中的Map性能較差，解決Hash採用的線性探測方法。

Netty就對它進行了優化，優化方式是繼承了Thread類，實現了本身的FastThreadLocal。它使用

搞不懂jdk，明明有O(1)的Map，非要本身造個更慢的輪子，爲何呢？話說，這個問題，簡直又偏到火星了。

設計秒殺系統要考慮哪些點?

一、數據預熱 秒殺都是瞬時操做，不要等流量來了再加載數據。能夠提早對數據進行預熱，好比加載到緩存等。

二、緩存 包括CDN緩存和數據緩存。保證緩存系統的高可用，數據隨後落地。

三、解決超賣 引入MQ，串行化操做庫存，達到閾值後再也不消費，並關閉購買功能。或者直接操做緩存。

四、流量削峯 經過引入MQ，將耗時業務進行削峯，平穩處理用戶需求。

五、熔斷限流 熔斷，優先保證主要業務的進行。限流，識別異常流量，進行封鎖；同時，容許部分請求失敗。

六、彈性擴容 在判斷系統負載達到極限時，能夠經過增長服務器的途徑抵抗峯值。須要打通運維環境，可以快速擴容。

怕就怕抓住一點問到底。秒殺個屁啊，淘寶的秒殺要麼搶不到，要麼500！

算了，杭州咱也不想去。下次試試阿里最爛的部門，看看要求是否是低點，能不能過。