我是如何進入阿里巴巴的-面向春招應屆生Java面試指南(八)

Java基礎

一、List 和 Set 的區別 List：1.能夠容許重複的對象。    2.能夠插入多個null元素。 3.是一個有序容器，保持了每一個元素的插入順序，輸出的順序就是插入的順序。 4.經常使用的實現類有 ArrayList、LinkedList 和 Vector。ArrayList 最爲流行，它提供了使用索引的隨意訪問，而 LinkedList 則對於常常須要從 List 中添加或刪除元素的場合更爲合適。 Set: 1.不容許重複對象    2. 無序容器，你沒法保證每一個元素的存儲順序，TreeSet經過 Comparator 或者 Comparable 維護了一個排序順序。 3. 只容許一個 null 元素 4.Set 接口最流行的幾個實現類是 HashSet、LinkedHashSet 以及 TreeSet。最流行的是基於 HashMap 實現的 HashSet；TreeSet 還實現了 SortedSet 接口，所以 TreeSet 是一個根據其 compare() 和 compareTo() 的定義進行排序的有序容器。

二、HashSet 是如何保證不重複的

HashSet是哈希表結構，當一個元素要存入HashSet集合時，首先經過自身的hashCode方法算出一個值，而後經過這個值查找元素在集合中的位置，若是該位置沒有元素，那麼就存入。若是該位置上有元素，那麼繼續調用該元素的equals方法進行比較，若是equals方法返回爲真，證實這兩個元素是相同元素，則不存。不然則在該位置上存儲2個元素（通常不可能重複）因此當一個自定義的對象想正確存入HashSet集合，那麼應該重寫Object的hashCode和equals。HashSet是經過hashCode()和equals()方法確保元素無序不重複的

公衆號推薦

• 全網惟一一個從0開始幫助Java開發者轉作大數據領域的公衆號~

• 大數據技術與架構或者搜索import_bigdata關注~

• 海量【java和大數據的面試題+視頻資料】整理在公衆號，關注後能夠下載~

三、HashMap 是線程安全的嗎，爲何不是線程安全的（最好畫圖說明多線程環境下不安全）? 當多個線程同時檢測到總數量超過門限值的時候就會同時調用resize操做，各自生成新的數組並rehash後賦給該map底層的數組table，結果最終只有最後一個線程生成的新數組被賦給table變量，其餘線程的均會丟失。並且當某些線程已經完成賦值而其餘線程剛開始的時候，就會用已經被賦值的table做爲原始數組，這樣也會有問題。 四、HashMap 的擴容過程 當HashMap的size達到臨界值capacity * loadFactor - 1時，HashMap會進行擴容，將自身容量增長一倍。

好比對未指定capacity和loadFactor的HashMap，缺省容量和負載因子分別爲16和0.75，所以當map中存儲的元素數量達到16 * 0.75 - 1即爲11時，該map會將自身容量擴大到2 * 16 = 32。 五、HashMap 1.7 與 1.8 的 區別，說明 1.8 作了哪些優化，如何優化的？ JDK1.7中 使用一個Entry數組來存儲數據，用key的hashcode取模來決定key會被放到數組裏的位置，若是hashcode相同，或者hashcode取模後的結果相同（hash collision），那麼這些key會被定位到Entry數組的同一個格子裏，這些key會造成一個鏈表。 在hashcode特別差的狀況下，比方說全部key的hashcode都相同，這個鏈表可能會很長，那麼put/get操做均可能須要遍歷這個鏈表 也就是說時間複雜度在最差狀況下會退化到O(n) JDK1.8中 使用一個Node數組來存儲數據，但這個Node多是鏈表結構，也多是紅黑樹結構 若是插入的key的hashcode相同，那麼這些key也會被定位到Node數組的同一個格子裏。 若是同一個格子裏的key不超過8個，使用鏈表結構存儲。 若是超過了8個，那麼會調用treeifyBin函數，將鏈表轉換爲紅黑樹。 那麼即便hashcode徹底相同，因爲紅黑樹的特色，查找某個特定元素，也只須要O(log n)的開銷 也就是說put/get的操做的時間複雜度最差只有O(log n) 六、final finally finalize final修飾符（關鍵字）。被final修飾的類，就意味着不能再派生出新的子類，不能做爲父類而被子類繼承。所以一個類不能既被abstract聲明，又被final聲明。將變量或方法聲明爲final，能夠保證他們在使用的過程當中不被修改。被聲明爲final的變量必須在聲明時給出變量的初始值，而在之後的引用中只能讀取。被final聲明的方法也一樣只能使用，不能重載。 finally是在異常處理時提供finally塊來執行任何清除操做。無論有沒有異常被拋出、捕獲，finally塊都會被執行。try塊中的內容是在無異常時執行到結束。catch塊中的內容，是在try塊內容發生catch所聲明的異常時，跳轉到catch塊中執行。finally塊則是不管異常是否發生，都會執行finally塊的內容，因此在代碼邏輯中有須要不管發生什麼都必須執行的代碼，就能夠放在finally塊中。 finalize是方法名。java技術容許使用finalize（）方法在垃圾收集器將對象從內存中清除出去以前作必要的清理工做。這個方法是由垃圾收集器在肯定這個對象沒有被引用時對這個對象調用的。它是在object類中定義的，所以全部的類都繼承了它。子類覆蓋finalize（）方法以整理系統資源或者被執行其餘清理工做。finalize（）方法是在垃圾收集器刪除對象以前對這個對象調用的。 七、強引用 、軟引用、 弱引用、虛引用 強引用： 只要引用存在，垃圾回收器永遠不會回收 Object obj = new Object(); //可直接經過obj取得對應的對象 如obj.equels(new Object()); 而這樣 obj對象對後面new Object的一個強引用，只有當obj這個引用被釋放以後，對象纔會被釋放掉，這也是咱們常常所用到的編碼形式。 軟引用： 非必須引用，內存溢出以前進行回收，能夠經過如下代碼實現 Object obj = new Object(); SoftReference sf = new SoftReference(obj); obj = null; sf.get();//有時候會返回null 這時候sf是對obj的一個軟引用，經過sf.get()方法能夠取到這個對象，固然，當這個對象被標記爲須要回收的對象時，則返回null； 軟引用主要用戶實現相似緩存的功能，在內存足夠的狀況下直接經過軟引用取值，無需從繁忙的真實來源查詢數據，提高速度；當內存不足時，自動刪除這部分緩存數據，從真正的來源查詢這些數據。 弱引用： 第二次垃圾回收時回收，能夠經過以下代碼實現 Object obj = new Object(); WeakReference wf = new WeakReference(obj); obj = null; wf.get();//有時候會返回null wf.isEnQueued();//返回是否被垃圾回收器標記爲即將回收的垃圾 弱引用是在第二次垃圾回收時回收，短期內經過弱引用取對應的數據，能夠取到，當執行過第二次垃圾回收時，將返回null。 弱引用主要用於監控對象是否已經被垃圾回收器標記爲即將回收的垃圾，能夠經過弱引用的isEnQueued方法返回對象是否被垃圾回收器標記。 虛引用： 垃圾回收時回收，沒法經過引用取到對象值，能夠經過以下代碼實現 Object obj = new Object(); PhantomReference pf = new PhantomReference(obj); obj=null; pf.get();//永遠返回null pf.isEnQueued();//返回是否從內存中已經刪除 虛引用是每次垃圾回收的時候都會被回收，經過虛引用的get方法永遠獲取到的數據爲null，所以也被成爲幽靈引用。 虛引用主要用於檢測對象是否已經從內存中刪除。

八、Java反射 一個程序員在寫程序的時須要使用第二個程序員所寫的類，但第二個程序員並沒完成他所寫的類。那麼第一個程序員的代碼是不能經過編譯的。此時，利用Java反射的機制，就可讓第一個程序員在沒有獲得第二個程序員所寫的類的時候，來完成自身代碼的編譯。 Java的反射機制它知道類的基本結構，這種對Java類結構探知的能力，咱們稱爲Java類的「自審」。如eclipse中，一按點，編譯工具就會自動的把該對象可以使用的全部的方法和屬性所有都列出來，供用戶進行選擇。這就是利用了Java反射的原理，是對咱們建立對象的探知、自審。

九、Arrays.sort 實現原理和 Collection 實現原理 Collections.sort的實現是Arrays.sort，java中Arrays.sort使用了兩種排序方法，快速排序和優化的合併排序。 快速排序主要是對哪些基本類型數據（int,short,long等）排序， 而合併排序用於對對象類型進行排序。 使用不一樣類型的排序算法主要是因爲快速排序是不穩定的，而合併排序是穩定的。這裏的穩定是指比較相等的數據在排序以後仍然按照排序以前的先後順序排列。對於基本數據類型，穩定性沒有意義，而對於對象類型，穩定性是比較重要的，由於對象相等的判斷可能只是判斷關鍵屬性，最好保持相等對象的非關鍵屬性的順序與排序前一直；另一個緣由是因爲合併排序相對而言比較次數比快速排序少，移動（對象引用的移動）次數比快速排序多，而對於對象來講，比較通常比移動耗時。 補充一點合併排序的時間複雜度是nlogn, 快速排序的平均時間複雜度也是nlogn，可是合併排序的須要額外的n個引用的空間

十、LinkedHashMap的應用 LinkedHashMap是Map接口的哈希表和連接列表實現，具備可預知的迭代順序。LinkedHashMap實現與HashMap的不一樣之處在於，LinkedHashMap維護着一個運行於全部條目的雙重連接列表。此連接列表定義了迭代順序，該迭代順序能夠是插入順序（insert-order）或者是訪問順序，其中默認的迭代訪問順序就是插入順序，便可以按插入的順序遍歷元素，這點和HashMap有很大的不一樣。 十一、cloneable接口實現原理 一、基本類型 若是變量是基本類型，則拷貝其值，好比：int、float、long等。 二、String字符串 這個比較特殊，拷貝的是地址，是個引用，可是在修改的時候，它會從字符串池（String Pool）中從新生成新的字符串，原有的字符串對象保持不變，此處能夠認爲String是個基本類型。 三、對象 若是變量時一個實例對象，則拷貝地址引用，也就是說此時新拷貝出的對象與原有對象共享該實例變量，不受訪問權限的限制。這在Java中很瘋狂，由於它突破了訪問權限的定義，一個private修飾的變量，居然能夠被兩個實例對象訪問。 十二、異常分類以及處理機制

1三、wait和sleep的區別 sleep 是讓線程進入阻塞狀態，必定時間以後回到非阻塞狀態，從而能夠從新得到 CPU。wait 調用的時候須要先得到該 Object 的鎖，調用 wait 後，會把當前的鎖釋放掉同時阻塞住；當別的線程調用該 Object 的 notify/notifyAll 以後，有可能獲得 CPU，同時從新得到鎖。因爲有如上描述鎖的設計，只要在 notify 的時候首先得到鎖，就能夠保證 notify 的時候或者處於 wait 線程得到鎖以前，或者正在 wait，從而保證不會丟掉此次 notify 信息。

1四、數組在內存中如何分配

一、簡單的值類型的數組，每一個數組成員是一個引用（指針），引用到棧上的空間（由於值類型變量的內存分配在棧上）

二、引用類型，類類型的數組，每一個數組成員還是一個引用（指針），引用到堆上的空間（由於類的實例的內存分配在堆上） Java 併發 一、synchronized 的實現原理以及鎖優化？ 二、volatile 的實現原理？ 三、Java 的信號燈？ 四、synchronized 在靜態方法和普通方法的區別？

1. 修飾一個代碼塊，被修飾的代碼塊稱爲同步語句塊，其做用的範圍是大括號{}括起來的代碼，做用的對象是調用這個代碼塊的對象；
2. 修飾一個方法，被修飾的方法稱爲同步方法，其做用的範圍是整個方法，做用的對象是調用這個方法的對象；
3. 修改一個靜態的方法，其做用的範圍是整個靜態方法，做用的對象是這個類的全部對象；
4. 修改一個類，其做用的範圍是synchronized後面括號括起來的部分，做用主的對象是這個類的全部對象。 五、怎麼實現全部線程在等待某個事件的發生纔會去執行？

六、CAS？CAS 有什麼缺陷，如何解決？

七、synchronized 和 lock 有什麼區別？

八、Hashtable 是怎麼加鎖的 ？

九、HashMap 的併發問題？

十、ConcurrenHashMap 介紹？1.8 中爲何要用紅黑樹？

紅黑樹是不符合AVL樹的平衡條件的，即每一個節點的左子樹和右子樹的高度最多差1的二叉查找樹。可是提出了爲節點增長顏色，紅黑是用非嚴格的平衡來換取增刪節點時候旋轉次數的下降，任何不平衡都會在三次旋轉以內解決，而AVL是嚴格平衡樹，所以在增長或者刪除節點的時候，根據不一樣狀況，旋轉的次數比紅黑樹要多。因此紅黑樹的插入效率更高！

紅黑樹的查詢性能略微遜色於AVL樹，由於他比avl樹會稍微不平衡最多一層，也就是說紅黑樹的查詢性能只比相同內容的avl樹最多多一次比較，可是，紅黑樹在插入和刪除上完爆avl樹，avl樹每次插入刪除會進行大量的平衡度計算，而紅黑樹爲了維持紅黑性質所作的紅黑變換和旋轉的開銷，相較於avl樹爲了維持平衡的開銷要小得多

十一、AQS

十二、如何檢測死鎖？怎麼預防死鎖？

1三、Java 內存模型？

1四、如何保證多線程下 i++ 結果正確？

1五、線程池的種類，區別和使用場景？

1六、分析線程池的實現原理和線程的調度過程？

1七、線程池如何調優，最大數目如何確認？

1八、ThreadLocal原理，用的時候須要注意什麼？

1九、CountDownLatch 和 CyclicBarrier 的用法，以及相互之間的差異?

20、LockSupport工具

2一、Condition接口及其實現原理

2二、Fork/Join框架的理解

2三、分段鎖的原理,鎖力度減少的思考

2四、八種阻塞隊列以及各個阻塞隊列的特性

Spring

一、BeanFactory 和 FactoryBean？

實現 BeanFactory 接口的類代表此類事一個工廠，做用就是配置、新建、管理 各類Bean。

而 實現 FactoryBean 的類代表此類也是一個Bean，類型爲工廠Bean（Spring中共有兩種bean，一種爲普通bean，另外一種則爲工廠bean）。顧名思義，它也是用來管理Bean的，而它自己由spring管理。

二、Spring IOC 的理解，其初始化過程？

Spring IOC的核心是BeanFactory

其實SpringIOC初始化的過程就是準備好BeanFactory的過程。

（1）定位並獲取資源文件 ClassPathResource res = new ClassPathResource("my/applicationContext.xml"); 由於對象和對象之間的關係存儲在xml或properties等語義化配置文件中，首先要定位到配置文件。用資源加載器ResourceLoader將資源文件路徑轉換爲對應的Resource

（2）解析資源文件 XmlBeanFactory bf = new XmlBeanFactory(res);

（3）註冊 DefaultListableBeanDefiniton.registerBeanDefiniton利用解析好的BeanDefinition對象完成最終的註冊。將beanName和BeanDefinition做爲鍵值放到了beanFactory的map中

三、BeanFactory 和 ApplicationContext？

若是說BeanFactory是Spring的心臟，那麼ApplicationContext就是完整的軀體了，ApplicationContext由BeanFactory派生而來，提供了更多面向實際應用的功能。在BeanFactory中，不少功能須要以編程的方式實現，而在ApplicationContext中則能夠經過配置實現。

BeanFactorty接口提供了配置框架及基本功能，可是沒法支持spring的aop功能和web應用。而ApplicationContext接口做爲BeanFactory的派生，於是提供BeanFactory全部的功能。並且ApplicationContext還在功能上作了擴展.

四、Spring Bean 的生命週期，如何被管理的？

Spring上下文中的Bean也相似，【Spring上下文的生命週期】

1. 實例化一個Bean，也就是咱們一般說的new
2. 按照Spring上下文對實例化的Bean進行配置，也就是IOC注入
3. 若是這個Bean實現了BeanNameAware接口，會調用它實現的setBeanName(String beanId)方法，此處傳遞的是Spring配置文件中Bean的ID
4. 若是這個Bean實現了BeanFactoryAware接口，會調用它實現的setBeanFactory()，傳遞的是Spring工廠自己（能夠用這個方法獲取到其餘Bean）
5. 若是這個Bean實現了ApplicationContextAware接口，會調用setApplicationContext(ApplicationContext)方法，傳入Spring上下文，該方式一樣能夠實現步驟4，但比4更好，覺得ApplicationContext是BeanFactory的子接口，有更多的實現方法
6. 若是這個Bean關聯了BeanPostProcessor接口，將會調用postProcessBeforeInitialization(Object obj, String s)方法，BeanPostProcessor常常被用做是Bean內容的更改，而且因爲這個是在Bean初始化結束時調用After方法，也可用於內存或緩存技術
7. 若是這個Bean在Spring配置文件中配置了init-method屬性會自動調用其配置的初始化方法
8. 若是這個Bean關聯了BeanPostProcessor接口，將會調用postAfterInitialization(Object obj, String s)方法 注意：以上工做完成之後就能夠用這個Bean了，那這個Bean是一個single的，因此通常狀況下咱們調用同一個ID的Bean會是在內容地址相同的實例
9. 當Bean再也不須要時，會通過清理階段，若是Bean實現了DisposableBean接口，會調用其實現的destroy方法
10. 最後，若是這個Bean的Spring配置中配置了destroy-method屬性，會自動調用其配置的銷燬方法 以上10步驟能夠做爲面試或者筆試的模板，另外咱們這裏描述的是應用Spring上下文Bean的生命週期，若是應用Spring的工廠也就是BeanFactory的話去掉第5步就Ok了 五、Spring Bean 的加載過程是怎樣的？ 六、若是要你實現Spring AOP，請問怎麼實現？ 七、若是要你實現Spring IOC，你會注意哪些問題？ 八、Spring 是如何管理事務的，事務管理機制？ 九、Spring 的不一樣事務傳播行爲有哪些，幹什麼用的？ 十、Spring 中用到了那些設計模式？ 十一、Spring MVC 的工做原理？ 十二、Spring 循環注入的原理？ 1三、Spring AOP的理解，各個術語，他們是怎麼相互工做的？ 1四、Spring 如何保證 Controller 併發的安全？

Netty

一、BIO、NIO和AIO

I/O能夠分爲兩種：同步IO和異步IO,同步I/O最多見的是 BIO(Blocking IO)、NIO(Non-Blocking IO)

BIO：是當發起I/O的讀或寫操做時，均爲阻塞方式，直到應用程序讀到了流或者將流寫入數據。

NIO：基於事件驅動思想，常採用reactor（反應器）模式。當發起 IO請求時，應用程序是非阻塞的。當SOCKET有流可讀或寫的時候，

由操做系統通知應用程序，應用程序再將流讀取到緩衝區或者寫入系統。

AIO：一樣基於事件驅動的思想，一般採用Proactor(前攝器模式)實現。在進行I/O操做時，直接調用API的read或write,這兩種方法

均爲異步。對於讀操做，操做系統將數據讀到緩衝區，並通知應用程序，對於寫操做，操做系統將write方法傳遞的流寫入並主動通知

應用程序。它節省了NIO中遍歷事件通知隊列的代價。 二、Netty 的各大組件

三、Netty的線程模型 netty經過Reactor模型基於多路複用器接收並處理用戶請求（能講就多講一點），內部實現了兩個線程池，boss線程池和work線程池，其中boss線程池的線程負責處理請求的accept事件，當接收到accept事件的請求時，把對應的socket封裝到一個NioSocketChannel中，並交給work線程池，其中work線程池負責請求的read和write事件

四、TCP 粘包/拆包的緣由及解決方法

一、發送端給每一個數據包添加包首部，首部中應該至少包含數據包的長度，這樣接收端在接收到數據後，經過讀取包首部的長度字段，便知道每個數據包的實際長度了。

二、發送端將每一個數據包封裝爲固定長度（不夠的能夠經過補0填充），這樣接收端每次從接收緩衝區中讀取固定長度的數據就天然而然的把每一個數據包拆分開來。

三、能夠在數據包之間設置邊界，如添加特殊符號，這樣，接收端經過這個邊界就能夠將不一樣的數據包拆分開。

五、瞭解哪幾種序列化協議？包括使用場景和如何去選擇 xml / json / protobuf/ thtift 六、Netty的零拷貝實現

七、Netty的高性能表如今哪些方面

分佈式相關 一、Dubbo的底層實現原理和機制

服務容器負責啓動，加載，運行服務提供者。

服務提供者在啓動時，向註冊中心註冊本身提供的服務。

服務消費者在啓動時，向註冊中心訂閱本身所需的服務。

註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。

服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

二、描述一個服務從發佈到被消費的詳細過程

本地有對遠程方法的描述，包括方法名、參數、返回值，在dubbo中是遠程和本地使用一樣的接口；而後呢，要有對網絡通訊的封裝，要對調用方來講通訊細節是徹底不可見的，網絡通訊要作的就是將調用方法的屬性經過必定的協議（簡單來講就是消息格式）傳遞到服務端；服務端按照協議解析出調用的信息；執行相應的方法；在將方法的返回值經過協議傳遞給客戶端；客戶端再解析；在調用方式上又能夠分爲同步調用和異步調用；簡單來講基本就這個過程

三、分佈式系統怎麼作服務治理

四、接口的冪等性的概念

冪等性是系統的接口對外一種承諾(而不是實現), 承諾只要調用接口成功, 外部屢次調用對系統的影響是一致的. 聲明爲冪等的接口會認爲外部調用失敗是常態, 而且失敗以後必然會有重試.

五、消息中間件如何解決消息丟失問題

RabbitMQ引入了消息確認機制，當消息處理完成後，給Server端發送一個確認消息，來告訴服務端能夠刪除該消息了，若是鏈接斷開的時候，Server端沒有收到消費者發出的確認信息，則會把消息轉發給其餘保持在線的消費者。

六、Dubbo的服務請求失敗怎麼處理

1.超時設置

DUBBO消費端設置超時時間須要根據業務實際狀況來設定， 若是設置的時間過短，一些複雜業務須要很長時間完成，致使在設定的超時時間內沒法完成正常的業務處理。 這樣消費端達到超時時間，那麼dubbo會進行重試機制，不合理的重試在一些特殊的業務場景下可能會引起不少問題，須要合理設置接口超時時間。 好比發送郵件，可能就會發出多份重複郵件，執行註冊請求時，就會插入多條重複的註冊數據。

2.重連機制

dubbo在調用服務不成功時，默認會重試2次。 Dubbo的路由機制，會把超時的請求路由到其餘機器上，而不是本機嘗試，因此 dubbo的重試機器也能必定程度的保證服務的質量。 可是若是不合理的配置重試次數，當失敗時會進行重試屢次，這樣在某個時間點出現性能問題，調用方再連續重複調用， 系統請求變爲正常值的retries倍，系統壓力會大增，容易引發服務雪崩，須要根據業務狀況規劃好如何進行異常處理，什麼時候進行重試。

七、重連機制會不會形成錯誤

八、對分佈式事務的理解

九、如何實現負載均衡，有哪些算法能夠實現？

十、Zookeeper的用途，選舉的原理是什麼？

十一、數據的垂直拆分水平拆分。

十二、zookeeper原理和適用場景

1三、zookeeper watch機制

一個Watch事件是一個一次性的觸發器，當被設置了Watch的數據發生了改變的時候，則服務器將這個改變發送給設置了Watch的客戶端，以便通知它們 1四、redis/zk節點宕機如何處理

1五、分佈式集羣下如何作到惟一序列號

1六、如何作一個分佈式鎖

1七、用過哪些MQ，怎麼用的，和其餘mq比較有什麼優缺點，MQ的鏈接是線程安全的嗎

1八、MQ系統的數據如何保證不丟失

1九、列舉出你能想到的數據庫分庫分表策略；分庫分表後，如何解決全表查詢的問題

20、zookeeper的選舉策略

2一、全局ID

數據庫

一、mysql分頁有什麼優化

第二種方法，在查詢下一頁時把上一頁的行id做爲參數傳遞給客戶端程序，而後sql就改爲了 select * from table where id>3000000 limit 10; 這條語句執行也是在毫秒級完成的，id>300w其實就是讓mysql直接跳到這裏了，不用依次在掃描全面全部的行 若是你的table的主鍵id是自增的，而且中間沒有刪除和斷點，那麼還有一種方式，好比100頁的10條數據 select * from table where id>100*10 limit 10;

二、悲觀鎖、樂觀鎖

三、組合索引，最左原則

多列字段作索引，state/city/zipCode，想要索引生效的話，只能使用以下的組合 state/city/zipCode state/city state

其餘方式（如city，city/zipCode），則索引不會生效 這種現象是怎麼致使的？和索引的存儲方式有關嗎？

本人頁參考了下其餘網友的觀點，我的認爲，所謂最左前綴原則就是先要看第一列，在第一列知足的條件下再看左邊第二列，以此類推。有位網友描述得很形象： 你能夠認爲聯合索引是闖關遊戲的設計

例如你這個聯合索引是state/city/zipCode

那麼state就是第一關 city是第二關， zipCode就是第三關

你必須匹配了第一關，才能匹配第二關，匹配了第一關和第二關，才能匹配第三關 你不能直接到第二關的

索引的格式就是第一層是state，第二層纔是city

索引是由於B+樹結構 因此查找快 若是單看第三列 是非排序的。 四、mysql 的表鎖、行鎖

五、mysql 性能優化

六、mysql的索引分類：B+，hash；什麼狀況用什麼索引

七、事務的特性和隔離級別

緩存

一、Redis用過哪些數據數據，以及Redis底層怎麼實現

二、Redis緩存穿透，緩存雪崩

三、如何使用Redis來實現分佈式鎖

四、Redis的併發競爭問題如何解決

1.獨佔鎖 2.樂觀鎖(版本號辦法)

3.採用排隊的機制進行。將全部須要對同一個key的請求進行入隊操做，而後用一個消費者線程從隊頭依次讀出請求，並對相應的key進行操做。

五、Redis持久化的幾種方式，優缺點是什麼，怎麼實現的

六、Redis的緩存失效策略

七、Redis集羣，高可用，原理

八、Redis緩存分片

範圍分片 hash分片 一致性hash

九、Redis的數據淘汰策略 最大緩存 在 redis 中，容許用戶設置最大使用內存大小 server.maxmemory，默認爲0，沒有指定最大緩存，若是有新的數據添加，超過最大內存，則會使redis崩潰，因此必定要設置。redis

內存數據集大小上升到必定大小的時候，就會實行數據淘汰策略。

主鍵失效

做爲一種按期清理無效數據的重要機制，在 Redis 提供的諸多命令中，EXPIRE、EXPIREAT、PEXPIRE、PEXPIREAT 以及 SETEX 和 PSETEX 都可以用來設置一條 Key-Value 對的失效時間，而一條 Key-Value 對一旦被關聯了失效時間就會在到期後自動刪除（或者說變得沒法訪問更爲準確）

淘汰機制

隨着不斷的向redis中保存數據，當內存剩餘空間沒法知足添加的數據時，redis 內就會施行數據淘汰策略，清除一部份內容而後保證新的數據能夠保存到內存中。 內存淘汰機制是爲了更好的使用內存，用必定得miss來換取內存的利用率，保證redis緩存中保存的都是熱點數據。 redis 提供 6種數據淘汰策略： voltile-lru：從已設置過時時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰 volatile-ttl：從已設置過時時間的數據集（server.db[i].expires）中挑選將要過時的數據淘汰 volatile-random：從已設置過時時間的數據集（server.db[i].expires）中任意選擇數據淘汰 allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰 allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰 no-enviction（驅逐）：禁止驅逐數據

JVM

一、詳細jvm內存模型 原子性 可見性 有序性

二、講講什麼狀況下回出現內存溢出，內存泄漏？ java 堆溢出 java棧溢出3. 方法區和運行時常量池溢出(PemGen)

三、說說Java線程棧

四、JVM 年輕代到年老代的晉升過程的判斷條件是什麼呢？ 年齡達到必定值(年齡閾值，能夠經過-XX:MaxTenuringThreshold來設置)的對象會被移動到年老代中

五、JVM 出現 fullGC 很頻繁，怎麼去線上排查問題？

六、類加載爲何要使用雙親委派模式，有沒有什麼場景是打破了這個模式？ 系統安全性：Java類隨着加載它的類加載器一塊兒具有了一種帶有優先級的層次關係。好比，Java中的Object類，它存放在rt.jar之中,不管哪個類加載器要加載這個類，最終都是委派給處於模型最頂端的啓動類加載器進行加載，所以Object在各類類加載環境中都是同一個類。若是不採用雙親委派模型，那麼由各個類加載器本身取加載的話，那麼系統中會存在多種不一樣的Object類。 tomcat打破了這一模型，先Classpath, 而後War包,當前工程, 最後纔是Tomcat相關目錄.

七、類的實例化順序

有父類的狀況

1. 加載父類 1.1 爲靜態屬性分配存儲空間並賦初始值 1.2 執行靜態初始化塊和靜態初始化語句（從上至下）
2. 加載子類 2.1 爲靜態屬性分配存儲空間 2.2 執行靜態初始化塊和靜態初始化語句（從上至下）
3. 加載父類構造器 3.1 爲實例屬性分配存數空間並賦初始值 3.2 執行實例初始化塊和實例初始化語句 3.3 執行構造器內容
4. 加載子類構造器 4.1 爲實例屬性分配存數空間並賦初始值 4.2 執行實例初始化塊和實例初始化語句 4.3 執行構造器內容

八、JVM垃圾回收機制，什麼時候觸發MinorGC等操做 Minor GC觸發條件：當Eden區滿時，觸發Minor GC。

Full GC觸發條件：

（1）調用System.gc時，系統建議執行Full GC，可是沒必要然執行

（2）老年代空間不足

（3）方法去空間不足

（4）經過Minor GC後進入老年代的平均大小大於老年代的可用內存

（5）由Eden區、From Space區向To Space區複製時，對象大小大於To Space可用內存，則把該對象轉存到老年代，且老年代的可用內存小於該對象大小

九、JVM 中一次完整的 GC 流程（從 ygc 到 fgc）是怎樣的

十、各類回收器，各自優缺點，重點CMS、G1

十一、各類回收算法

十二、OOM錯誤，stackoverflow錯誤，permgen space錯誤

公衆號推薦

• 全網惟一一個從0開始幫助Java開發者轉作大數據領域的公衆號~

• 大數據技術與架構或者搜索import_bigdata關注~

• 海量【java和大數據的面試題+視頻資料】整理在公衆號，關注後能夠下載~