一面

自我介紹下自己，不超過3分鐘（實際上我的自我介紹不到一分鐘） 你感覺比本科階段自己進步了多少，有哪些進步 研究生期間最大的進步是什麼 你覺得你適合從事哪個方向的開發 synchronized與lock的區別，使用場景。看過synchronized的源碼沒 JVM自動內存管理，Minor GC與Full GC的觸發機制 瞭解過JVM調優沒，基本思路是什麼

如果CPU使用率較高，GC頻繁且GC時間長，可能就需要JVM調優了。 基本思路就是讓每一次GC都回收儘可能多的對象， 對於CMS來說，要合理設置年輕代和年老代的大小。該如何確定它們的大小呢？這是一個迭代的過程，可以先採用JVM的默認值，然後通過壓測分析GC日誌。

如果看年輕代的內存使用率處在高位，導致頻繁的Minor GC，而頻繁GC的效率又不高，說明對象沒那麼快能被回收，這時年輕代可以適當調大一點。

如果看年老代的內存使用率處在高位，導致頻繁的Full GC，這樣分兩種情況：如果每次Full GC後年老代的內存佔用率沒有下來，可以懷疑是內存洩漏；如果Full GC後年老代的內存佔用率下來了，說明不是內存洩漏，要考慮調大年老代。

對於G1收集器來說，可以適當調大Java堆，因為G1收集器採用了局部區域收集策略，單次垃圾收集的時間可控，可以管理較大的Java堆。

如何設計存儲海量數據的存儲系統

海量數據的解決方案： 頁面上： 使用緩存；頁面靜態化技術； 數據庫層面： 分離數據庫中活躍的數據；批量讀取和延遲修改；讀寫分離；使用NoSQL和Hadoop等技術；分佈式部署數據庫；應用服務和數據服務分離； 其他方面： 使用搜索引擎搜索數據庫中的數據；進行業務的拆分； 高併發情況下的解決方案： 應用程序和靜態資源文件進行分離，靜態資源可以使用CDN； 集群與分佈式； 使用Nginx反向代理；

緩存的實現原理，設計緩存要注意什麼 將熱點數據放在內存中，用戶查詢時命中內存中的數據而不用到數據庫中查詢 注意緩存的一致性，緩存雪崩、擊穿、穿透的問題

淘寶熱門商品信息在JVM哪個內存區域 ？？，不應該在緩存中嘛，然後落地在數據庫裡，跟JVM有屁關係 操作系統的頁式存儲 把內存分成大小相同的內存頁，然後程序通過頁表來查詢到自己的存儲位置，這樣就可以使用不連續的內存來加載程序 事實上現在都用虛擬內存的方式，把程序分段加載到虛擬內存中，再把內存分頁，通過段表、頁表的形式來映射程序在內存中的位置 volatile關鍵字的如何保證內存可見性 volatile修飾的變量保證其每個寫操作後都更新到主內存，每個讀操作都到主內存中更新，具體的話是在JVM層面，在修飾的變量前後加關鍵字 順帶一提volatile還能防止指令重排，這兩者的實現方式都是內存屏障。

happen-before原則 如果前一個操作的執行結果必須對後一個操作可見，那就不允許這兩個操作進行重排序，且happen-befor具有傳遞性 Lucene全文搜索的原理 先將全文由分詞器進行分詞，會提取出關鍵詞和頻率，然後這個關鍵詞後面也會跟著一個鏈表，這個鏈表記錄了有個關鍵詞的文檔。我們通過關鍵詞搜索就可以找到這串鏈表，也就得到了所要的文檔了。 你覺得自己適合哪方面的開發，為什麼 JavaWeb的後端開發，一個當然是對這方面感興趣，涉及範圍廣，然後目前掌握的比較多的也是這方面的內容，技能比較熟練，自己認識的圈子也是這個圈子裡的人，如果遇到問題也容易解決，自己也有一套這方面的學習方法，如果去學習其他的話，倒不是走出舒適區的問題，而是對於現階段的我來說，不能做到在短時間內取得階段性的成果 想去哪裡實習，杭州？

二面

自我介紹下自己，不超過3分鐘（我的自我介紹仍然不超過1分鐘） 你說你熟悉併發編程，那麼你說說Java鎖有哪些種類，以及區別（果然深度不一樣） 公平鎖/非公平鎖 這個是在ReentrankLock中實現的，synchronized沒有，是用一個隊列實現的，在公平鎖好理解，就是先進這個隊列的，也先出隊列獲得資源，而非公平鎖的話，則是還沒有進隊列之前可以與隊列中的線程競爭嘗試獲得鎖，如果獲取失敗，則進隊列，此時也是要乖乖等前面出隊才行 可重入鎖 如果一個線程獲得過該鎖，可以再次獲得，主要是用途就是在遞歸方面，還有就是防止死鎖，比如在一個同步方法塊中調用了另一個相同鎖對象的同步方法塊 獨享鎖/共享鎖 共享鎖可以由多個線程獲取使用，而獨享鎖只能由一個線程獲取。 對ReentrantReadWriteLock其讀鎖是共享鎖，其寫鎖是獨佔鎖 讀鎖的共享鎖可保證併發讀是非常高效的，讀寫，寫讀，寫寫的過程是互斥的。其中獲得寫鎖的線程還能同時獲得讀鎖，然後通過釋放寫鎖來降級。讀鎖則不能升級 互斥鎖/讀寫鎖 上面講的獨享鎖/共享鎖就是一種廣義的說法，互斥鎖/讀寫鎖就是具體的實現。 互斥鎖在Java中的具體實現就是ReentrantLock 讀寫鎖在Java中的具體實現就是ReadWriteLock 樂觀鎖/悲觀鎖 樂觀鎖就是樂觀的認為不會發生衝突，用cas和版本號實現 悲觀鎖就是認為一定會發生衝突，對操作上鎖 分段鎖 在1.7的concurrenthashmap中有分段鎖的實現，具體為默認16個的segement數組，其中segement繼承自reentranklock，每個線程過來獲取一個鎖，然後操作這個鎖下連著的map。 偏向鎖/輕量級鎖/重量級鎖 在jdk1.6中做了第synchronized的優化， 偏向鎖指的是當前只有這個線程獲得，沒有發生爭搶，此時將方法頭的markword設置成0，然後每次過來都cas一下就好，不用重複的獲取鎖 輕量級鎖：在偏向鎖的基礎上，有線程來爭搶，此時膨脹為輕量級鎖，多個線程獲取鎖時用cas自旋獲取，而不是阻塞狀態 重量級鎖：輕量級鎖自旋一定次數後，膨脹為重量級鎖，其他線程阻塞，當獲取鎖線程釋放鎖後喚醒其他線程。（線程阻塞和喚醒比上下文切換的時間影響大的多，涉及到用戶態和內核態的切換） 自旋鎖：在沒有獲取鎖的時候，不掛起而是不斷輪詢鎖的狀態

如何保證內存可見性 volatile 通過內存屏障 synchronized 通過修飾的程序段同一時間只能由同一線程運行，釋放鎖前會刷新到主內存

Http請求的過程與原理 三次握手與四次揮手？ 通過HTTP網絡請求過程中的TCP協議 TCP連接的特點 相較於UDP來說，更加安全可靠,是面向連接，傳輸的話是以流的形式傳輸 TCP連接如何保證安全可靠的 為什麼TCP連接需要三次握手，兩次不可以嗎，為什麼 不可以兩次握手只能一方確認自己的收發沒有問題，而另一方的收沒問題，發可能存在問題 AOP的原理 靜態織入，動態代理 JDK動態代理與cglib實現的區別（這個，醉得很厲害） 接口（反射）/繼承 那麼你說說代理的實現原理唄 1.創建一個接口 2.創建一個實現了這個接口的實現類 3.創建一個實現了這個接口的代理類，在代理類中實例化實現類，並且調用實現類中的方法 看過Spring源碼沒，說說Ioc容器的加載過程吧 簡單概括： 1.刷新預處理 2.將配置信息解析，註冊到BeanFactory 3.設置bean的類加載器 4.如果有第三方想再bean加載註冊完成後，初始化前做點什麼(例如修改屬性的值，修改bean的scope為單例或者多例。)，提供了相應的模板方法，後面還調用了這個方法的實現，並且把這些個實現類註冊到對應的容器中 5.初始化當前的事件廣播器 6.初始化所有的bean 7.廣播applicationcontext初始化完成。

<code>//來自於AbstractApplicationContext
public void refresh() throws BeansException, IllegalStateException {
       //進行加鎖處理
   synchronized (this.startupShutdownMonitor) {
       // 進行刷新容器的準備工作，比如設定容器開啟時間，標記容器已啟動狀態等等
       prepareRefresh();

       // 讓子類來刷新創建容器
       // 這步比較關鍵，這步完成後，配置文件就會解析成一個個 Bean 定義，註冊到 BeanFactory 中，
       // 當然，這裡說的 Bean 還沒有初始化，只是配置信息都提取出來了，
       // 註冊也只是將這些信息都保存到了註冊中心(說到底核心是一個 beanName-> beanDefinition 的 map)
       ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();

       // 設置 BeanFactory 的類加載器，添加幾個 BeanPostProcessor，手動註冊幾個特殊的 bean
       prepareBeanFactory(beanFactory);

       try {
           // 這裡需要知道 BeanFactoryPostProcessor 這個知識點，
           //Bean 如果實現了此接口，那麼在容器初始化以後，Spring 會負責調用裡面的 postProcessBeanFactory 方法。
           // 這裡是提供給子類的擴展點，到這裡的時候，所有的 Bean 都加載、註冊完成了，但是都還沒有初始化
           // 具體的子類可以在這步的時候添加一些特殊的 BeanFactoryPostProcessor 的實現類或做點什麼事
           postProcessBeanFactory(beanFactory);
 

           // 調用 BeanFactoryPostProcessor 各個實現類的 postProcessBeanFactory(factory) 方法
           invokeBeanFactoryPostProcessors(beanFactory);

           // 註冊 BeanPostProcessor 的實現類，注意看和 BeanFactoryPostProcessor 的區別
           // 此接口兩個方法: postProcessBeforeInitialization 和 postProcessAfterInitialization
           // 兩個方法分別在 Bean 初始化之前和初始化之後得到執行。注意，到這裡 Bean 還沒初始化
           registerBeanPostProcessors(beanFactory);

           // 初始化當前 ApplicationContext 的 MessageSource
           initMessageSource();

           // 初始化當前 ApplicationContext 的事件廣播器
           initApplicationEventMulticaster();

           // 從方法名就可以知道，典型的模板方法(鉤子方法)，
           // 具體的子類可以在這裡初始化一些特殊的 Bean（在初始化 singleton beans 之前）
           onRefresh();

           // 註冊事件監聽器，監聽器需要實現 ApplicationListener 接口
           registerListeners();

           // 初始化所有的 singleton beans（lazy-init 的除外）
           // 重點方法將會在下一個章節進行說明
           finishBeanFactoryInitialization(beanFactory);

           // 最後，廣播事件，ApplicationContext 初始化完成
           finishRefresh();
           }
           catch (BeansException ex) {
               if (logger.isWarnEnabled()) {
                   logger.warn("Exception encountered during context initialization - cancelling refresh attempt: " + ex);
               } 

                   // 銷燬已經初始化的 singleton 的 Beans，以免有些 bean 會一直佔用資源
                   destroyBeans();

                   // Reset 'active' flag.
                   cancelRefresh(ex);

                   // 把異常往外拋
                   throw ex;
             }
             finally {
               // Reset common introspection caches in Spring's core, since we
               // might not ever need metadata for singleton beans anymore...
               resetCommonCaches();
             }
     }
}/<code>

瞭解過字節碼的編譯過程嗎（這個還真不知道）

三面

自我介紹，不超過3分鐘（這次好像時間更久了，也就2分鐘多點） 說一下你對哪個項目比較熟悉 數據庫項目 為什麼做這個項目 當時公司裡為了整改balabala 項目採用了什麼架構，數據庫如何設計的 簡單是MVC架構，數據庫 數據庫由哪些表，為什麼有這些表

主要有哪些核心模塊，模塊之間如

如何保存會話狀態，有哪些方式、區別如何 cookie 保存在客戶端，容易篡改 session 保存在服務端，連接較大的話會給服務端帶來壓力，分佈式的情況下可以放在數據庫中， 優點： 1：簡單且高性能 2：支持分佈式與集群 3：支持服務器斷電和重啟 4：支持 tomcat、jetty 等運行容器重啟 缺點： 1、需要檢查和維護session過期，手動維護cookie； 2、不能有頻繁的session數據存取；

token 多終端或者app的話一定要這個， 隨著技術的發展，分佈式web應用的普及，通過session管理用戶登錄狀態成本越來越高，因此慢慢發展成為token的方式做登錄身份校驗，然後通過token去取redis中的緩存的用戶信息，隨著之後jwt的出現，校驗方式更加簡單便捷化，無需通過redis緩存，而是直接根據token取出保存的用戶信息，以及對token可用性校驗，單點登錄更為簡單。

JWT的token包含三部分數據：

1. Header：頭部，通常頭部有兩部分信息： 聲明類型，這裡是JWT 加密算法，自定義
   我們會對頭部進行base64加密（可解密），得到第一部分數據
2. Payload：載荷，就是有效數據，一般包含下面信息： 用戶身份信息（注意，這裡因為採用base64加密，可解密，因此不要存放敏感信>息） 註冊聲明：如token的簽發時間，過期時間，簽發人等
   
   這部分也會採用base64加密，得到第二部分數據
3. Signature：簽名，是整個數據的認證信息。一般根據前兩步的數據， 再加上服務的>的密鑰（secret）
   （不要洩漏，最好週期性更換），通過加密算法生成。用於驗證整個數據完整和可靠性（不要洩漏，最好週期性更換），
   通過加密算法生成。用於驗證整個數據完整和可靠性

分佈式session如何管理，你有哪些方案 Redis做緩存持久化存儲session 數據庫存儲session

學過數據結構和算法嗎（當然），你說說二分搜索的過程 二分搜索有一點要求就是數據有已經排序好的，假設是自然排序的，拿到目標數據後查找中間的值，如果大了，就去右邊一部分的中間值比較，小了就去左邊一部分的中間值

說一下快排的過程，寫一下偽代碼 取一個值，然後設置兩個指針，一個指針先從後到前開始遍歷，遇到小於這個值的就停止，然後另一個指針從前到後遍歷，遇到大於這個值的就停止，知道這兩個指針相遇，此時交換這個值與相遇的時候指針的值，以這個座標為邊界兩邊開始遞歸

瞭解哪設計模式，舉例說說在jdk源碼哪些用到了你說的設計模式 單例：ioc容器 模板：ioc、springmvc 建造者模式：lombok 工廠：ioc 代理：aop 訂閱/發佈：消息隊列，redis的pub/sub

你有什麼問我嗎（仍然上面三個問題）

四面：

來個自我介紹唄，不超過3分鐘 介紹下你最熟悉的項目 項目使用了什麼架構，亮點是什麼 MVC，用到Lucene，用aop實現了權限的管理 平時主要學習什麼課程 Java、數據結構、數學建模 你目前的研究方向是什麼 家是哪的 喜歡看什麼書

大概什麼時候能來實習呢 四面總結

五面

自我介紹下吧 做了哪些項目 看你在問題中說你在杭州看到很多商販使用付款二維碼，你對支付寶怎麼看 每天有那麼多人使用支付寶，這些數據如果給你存儲，你會怎麼設計呢（不是說HR不問技術問題嗎？不愧是阿里的HR） 為什麼想來支付寶實習呢 技術棧、對移動支付比較好奇， 你身邊同學如何評價你、老師呢 如果與同事發生了意見的不一致，你會如何解決呢 首先就是要確保雙方都理解了對方的意思，因為有些是溝通不充分導致的，然後同時綜合對比不同意見，可能會對工作內容產生的影響，並且會根據利弊來選擇方法

閱讀更多 Java小馬哥 的文章

關鍵字: 美好，一直在身邊 自我介紹 NoSQL