Java面試總結（二）

前幾天去了幾家公司面試，果真，基本所有倒在二面上，無語啊。。。不過幸虧，到最後拿到了環球易購的offer，打算就這麼好好呆着了，學習學習，努力努力，下面講講這幾天的面試吧。
　　先是恆大，一個組長面試，答的很通常吧，有些問題是確實不知道題意，如何設計一個多線程，用來表示一個紅綠燈和車流的關係；還有人走迷宮的時候，如何用一個設計模式表示人的多樣性和路的多樣性；還有就是如何大批量向數據庫插入數據，這個以前沒關注過，沒答出來，有點遺憾。還有就是薪資問題，來以前我覺得恆大，這麼牛逼的公司，要不要提升一下薪資要求，不過爲了穩妥仍是繼續9-10k，面試官說剛畢業的，這邊只能給到8k左右啊，，，，就這樣，掛了。
　　達飛金控一面問的問題真的太基礎，基礎到有點嚇人，差很少也是那種set、list、map區別，抽象和接口什麼的，答得通常吧。因爲面試官在開會，開到了12點多，而後繼續面試，同時還有另外一個面試的在等，二面也聊得還算是蠻順暢，問了若是不當心發送了兩個重複的請求，因爲不一樣機房，數據同步須要時間，那麼如何解決這個請求；還有就是在一段文字中找出出現次數最多的字謎，整體上來的還算是通常偏上吧，答得也七七八八，而後就1點了，還有另一我的在等面試，最後說等消息，到如今也沒消息，又掛了。。。。蛇口那邊的環境確實不錯，面完下樓，好多外國人。還有就是達飛準備招人作風控、電商方面的業務，有須要的能夠投一下。
　　聯想的有點，，，對着一張紙的題直接說出答案，這個面試官說答的還不錯，而後是手寫sql和上機筆試，sql沒寫對（考察分頁，group by，having），其實不難的，只是平時不注意，上機的題也沒全作出來（考察Java日期類的使用，有點古老），不過還好有個本身的網站二面仍是過了，三面，額，可能作得東西跟本身想的不同，當我說我想作分佈式、高併發、高可用的東西以後，而後還問了部門manager併發量有多大，他說主要是給內部使用的，因此併發量不打，而後說等消息吧，就這麼掛了，聽說聯想2020年在後海會落成一棟樓，感受屌屌的，惋惜了。。。。
永遠掛在二面的我啊
　　深圳想去的公司而且招人的，基本投完了，而後這麼多都是倒在了二面，有點不甘心吧。在boss上偶然看到環球易購在招人，並且一直是本身求之不得的電商行業，就在boss上找環球易購的那些技術負責人，一個一個問，還好有位大佬理我，雖然不合適，但幫忙推到了另外一個組，而後等HR電話，一直沒答來，因此只能一直貫徹本身的方針：成功的三要素是，一堅持，二不要臉，三堅持不要臉，一直請問那位技術大佬，雖然特別很差意思。咱們常常說，千里馬常有而伯樂不常有，那麼一隻不要臉的普通馬就只能本身爭取了23333。
　　週一去了環球易購，面試官挺直接的，感受好像大概知道我實力如何什麼的，直接問難度稍微大一點點的問題，有點慌，並且回答的也不是太好，雙親委派還記反了（尷尬），而後是部門經理，這個我回答的更慘，慘不忍睹，問了tomcat如何解析一個請求，意思是tomcat源碼看過沒，，，，真的超級慌，當初看了一會源碼就沒堅持下去直接放棄了。不過還好能HR面了（終於有家公司是HR面了），中間件畢竟是我特別想整的東西。週三接到了offer，開心的一晚睡不着（加上沒工做做息時間混亂），致使今天體檢血壓一直高，，，，如今真是超級累。
　　這年頭找工做真的很累，最好不要像我同樣裸辭，找不到工做內心真的很不舒服的，特別容易心態爆炸，有時候以爲本身表現的還不錯，但就是沒過，很離譜的那種，畢竟面試，運氣緣分什麼的佔比更重。我是由於在上家公司加班太嚴重，並且任務太忙，根本沒時間面試和學習因此裸辭的。
　　下面是本身印象深入的題吧，有面試的能夠參考參考，答案不必定準確，由於我本身也是半斤八兩，也歡迎你們幫忙提醒一下。

1.MQ事務，若是消費者消費了，如何回滾

　　分佈式事務，是我計劃下下一階段要看的東西（下一個是分佈式鎖），沒想到這麼快就被問到了，最初看的不過也就CAP、BASE、2PC、3PC這些，MQ事務真的不多接觸。即便沒學過，那就按本身的理解來吧。假設有三個事務：A、B、C。
（1）若是三個事務以前不須要彼此的依賴，能夠執行完A的時候向消息隊列發送一個prepareA，同理，B、C也同樣，若是三個事務在本地都執行成功了，那麼發送一次success，而後事務prepareA、prepareB、prepareC開始執行，若是有一個失敗，則直接回滾全部。
（2）若是事務B須要依賴A的結果、C須要依賴B的結果，那麼A執行完後再執行B，B執行完再執行C，到最後，其中若是有一個失敗，則回滾重試。
　　這一塊是真沒接觸過，即便百度了，感受也有點抽象，仍是先把ZooKeeper的分佈式鎖看完再整分佈式事務的東西吧。百度的時候看到了一個比較相似的想法，說的比我好，能夠看看。

參考：
分佈式事務之最終一致的Mq實現
聊聊分佈式事務，再說說解決方案

2.主線程如何捕獲子線程的異常

　　這道題不是很理解他的意思，try catch不就好了？他說不是這個意思，我說用線程池的話能夠用callable異步返回異常結果，他說這個不算吧，一臉懵逼的狀態，過後百度了下發現考點是UncaughtExceptionHandler。。。大概意思就是把線程交給線程組，而後再線程組裏重寫異常捕獲方法，便可在主線程捕獲子線程的異常了，例子以下：

public class ThreadExcep extends ThreadGroup {
    private ThreadExcep() {
        super("線程組的名字");
    }
    public void uncaughtException(Thread thread, Throwable exception) {
        System.out.println(thread.getId());
        exception.printStackTrace();//example,   print   stack   trace
    }
    public static void main(String[] args) {
        ThreadExcep excep = new ThreadExcep();
        Thread thread = new Thread(excep, () -> {
            throw new NullPointerException("空指針異常");
        });
        thread.start();
    }
}

結果以下：

11
java.lang.NullPointerException: 空指針一場
    at com.study.exception.ThreadExcep.lambda$main$0(ThreadExcep.java:26)
    at java.lang.Thread.run(Thread.java:748)

　　而若是去掉exception.printStackTrace()，程序是不打印報錯信息的。緣由能夠總結以下：
（1）若是在主線程中建立一個子線程，默認狀況下這兩個線程同屬於一個線程組，若是子線程發生異常，主線程能夠直接使用try catch捕獲的到。
（2）一樣是在主線程中建立一個子線程，若是聲明瞭這個子線程是另外一個線程組的，即調用了new Thread(ThreadGroup group, Runnable target)，則主線程中是沒法直接捕獲到子線程的發生的異常的，不過能夠經過在聲明一個線程組重寫uncaughtException，而後把子線程放進去。
無論怎麼說，在主線程中捕獲子線程的異常通常是不推薦的，線程設計的理念：「線程的問題應該線程本身自己來解決，而不要委託到外部。」
參考：
【Java 多線程】Java中主線程如何捕獲子線程拋出的異常

3.大批量插入數據庫如何優化

　　大批量，以前都沒怎麼注意過，這個問題確實不會，網上參考了下別人的，大致上是這個意思：合併數據+事務的方法在較小數據量時，性能提升是很明顯的，數據量較大時（1千萬以上），性能會急劇降低，這是因爲此時數據量超過了innodb_buffer的容量，每次定位索引涉及較多的磁盤讀寫操做，性能降低較快。而使用合併數據+事務+有序數據的方式在數據量達到千萬級以上表現依舊是良好，在數據量較大時，有序數據索引定位較爲方便，不須要頻繁對磁盤進行讀寫操做，因此能夠維持較高的性能。

參考：
數據庫大批量SQL插入性能優化

4.Spring Bean的生命週期

　　Spring的源碼確實要找個時間好好看看了，下面的是參考自《Spring實戰的》內容。

主要流程以下：
(1).Spring對Bean進行實例化（至關於程序中的new Xx()）
(2).Spring將值和Bean的引用注入進Bean對應的屬性中
(3).若是Bean實現了BeanNameAware接口，Spring將Bean的ID傳遞給setBeanName()方法（實現BeanNameAware清主要是爲了經過Bean的引用來得到Bean的ID，通常業務中是不多有用到Bean的ID的）
(4).若是Bean實現了BeanFactoryAware接口，Spring將調用setBeanDactory(BeanFactory bf)方法並把BeanFactory容器實例做爲參數傳入。（實現BeanFactoryAware 主要目的是爲了獲取Spring容器，如Bean經過Spring容器發佈事件等）
(5).若是Bean實現了ApplicationContextAwaer接口，Spring容器將調用setApplicationContext(ApplicationContext ctx)方法，把y應用上下文做爲參數傳入.(做用與BeanFactory相似都是爲了獲取Spring容器，不一樣的是Spring容器在調用setApplicationContext方法時會把它本身做爲setApplicationContext 的參數傳入，而Spring容器在調用setBeanDactory前須要程序員本身指定（注入）setBeanDactory裏的參數BeanFactory )
(6).若是Bean實現了BeanPostProcess接口，Spring將調用它們的postProcessBeforeInitialization（預初始化）方法（做用是在Bean實例建立成功後對進行加強處理，如對Bean進行修改，增長某個功能）
(7).若是Bean實現了InitializingBean接口，Spring將調用它們的afterPropertiesSet方法，做用與在配置文件中對Bean使用init-method聲明初始化的做用同樣，都是在Bean的所有屬性設置成功後執行的初始化方法。
(8).若是Bean實現了BeanPostProcess接口，Spring將調用它們的postProcessAfterInitialization（後初始化）方法（做用與6的同樣，只不過6是在Bean初始化前執行的，而這個是在Bean初始化後執行的，時機不一樣 )
(9).通過以上的工做後，Bean將一直駐留在應用上下文中給應用使用，直到應用上下文被銷燬
(10).若是Bean實現了DispostbleBean接口，Spring將調用它的destory方法，做用與在配置文件中對Bean使用destory-method屬性的做用同樣，都是在Bean實例銷燬前執行的方法。

參考：
1.《Spring實戰》
2.Spring中Bean的生命週期是怎樣的？

5.Tomcat是如何解析一個請求的

萬萬沒想到啊，本身曾經研究過一點點tomcat的源碼，如今卻忘光了，留張圖先吧，以後寫源碼分析的系列。

6.代理模式（Spring）

這題以後看Spring源碼的時候再總結了。

7.Java類裏的靜態變量在JVM中哪一個區

JDK8以前，靜態成員變量確實存放在方法區；但JDK8以後就取消了「永久代」，取而代之的是「元空間」，永久代中的數據也進行了遷移，靜態成員變量遷移到了堆中（方法區是JVM的規範，永久代是方法區的具體實現）。

8.ORM的好處，爲何使用ORM

驚不驚喜，意不意外，大部分人都在用ORM，可是卻不多關注爲何吧。Object-Relationl Mapping，它的做用是在關係型數據庫和對象之間做一個映射，這樣，咱們在具體的操做數據庫的時候，就不須要再去和複雜的SQL語句打交道，只要像平時操做對象同樣操做它就能夠了 。
優勢
（1）方便的使用面向對象來進行額外的操做，語句清晰
（2）防注入
（3）方便動態構造語句，對於不一樣的表的相同操做採用多態實現更優雅
（4）必定程度方便重構數據層『好比改表名，字段名等』
缺點
（1）不太容易處理複雜查詢語句
（2）性能較直接用SQL差，畢竟有個轉化過程更。

總結

這些日子的面試過程，有基礎的，有廣度的，也暴露了本身不少不少缺點，2018還得繼續努力，最怕的是比你厲害的人還比你努力吧，不過怎麼說，但願各位在求職穩住心態，猥瑣發育，前程似錦。