從深圳回武漢的面試感想以及一些面試題

從深圳回武漢的面試感想以及一些面試題

你們好，我是ITDragon龍，今天分享一些面試中常問的題目，和一些面試感覺。我是四月二十五號離職，二十六號上午八點從深圳出發，下午三點到武漢。二十七號便開始參加面試。天天的節奏基本是：上午去公司面試，中午去小區房子裝修監工，下午再去公司面試，中途還有幾個電話面試，晚上再把印象深入的面試題弄清楚。回來的這幾天痩了幾斤肉！這幾天的面試給我不少感覺。

1、面試的幾家公司大部分是北上廣深在武漢創建的研發部門。緣由很簡單，武漢人才性價比高。

2、面試的幾家公司大部分面試官都會很直接告訴你加班強度很大。

3、無關技術，從深圳回到武漢，工資大概要打七折。緣由嘛，五花八門。

4、灰常的堵，特別是光谷軟件園，電動車都不看紅綠燈，各類瞎闖。

由於房子和交通，我選擇公司的範圍縮小了不少。由於回來匆忙，對於面試題和公司都沒有很好的瞭解，所以在面試中一直處於劣勢。如今把本身的面試經驗分享出來，幫你們把部分坑填平。預祝你們都能拿高薪。我這炮灰的做用也算是盡職了。

找工做不將就

找工做不能將就，不能進公司後發現不滿意而選擇離職，這樣對本身和對公司都有損失。因此一開始就要問清楚。如下是我比較在乎的四個點，僅供參考。

1、加班強度：如今程序員加班已成常態，產品發佈還要等到夜深人靜的時候。我以爲程序員就像一支蠟燭，燃燒本身照亮世界。加班必定要適量。不加，老闆不會放過你！多加，醫生也不會放過你！因此我但願加班強度不能太大。

2、出差頻率：有的人喜歡出差，有的人不喜歡出差，好比我。

3、額外待遇：好比每個月的績效獎金，項目現金，一年的年終獎。年終獎必定要問清楚：未滿一年的是怎麼計算？發的是基本工資？除了每個月固定工資外，必定要有其餘額外福利，否則動力從何而來。

4、接觸領域：若是有機會進入貴公司，最好問清楚接觸的技術領域，最好是主流的技術。不建議推倒車。

你須要清楚一點：你用一個月加班換來的錢，還不夠在醫院消費一次。

技術面試題

你須要清楚一點：回答技術問題的時候，面試官但願聽到更多的答案

IO和NIO的區別

這是一個很常見的問題，若是單純的只回答IO和NIO的區別，只能算及格。我我的以爲應該從如下幾個方面回答：

1）、IO簡介，

2）、TCP的三次握手，由於這也是二者的區別之一，

3）、NIO簡介，

IO：（Block-IO）是一種阻塞同步的通訊模式。是一個比較傳統的通訊方式，模式簡單，使用簡單。但併發處理能力低（每次鏈接都會建立新的線程進行鏈路處理），通訊耗時（TCP三次握手），依賴網速。

TCP三次握手：

第一次握手：創建鏈接，客戶端發送syn包到服務器端，等待服務器確認

第二次握手：服務器收到客戶端傳來的syn包，給客戶端返回ack和syn包，等待客戶端確認

第三次握手：客戶端收到服務器傳來的ack+ayn包，向服務器發送ack包，鏈接創建成功

NIO：（New IO / Non-Block IO）是一種非阻塞同步的通訊模式。客戶端和服務器之間經過Channel通訊（避免TCP創建鏈接使用三次握手帶來的開銷）。NIO在Channel進行讀寫操做。這些Channel都會被註冊在Selector多路複用器上。Selector經過一個線程不停的輪詢這些Channel。找出已經準備就緒的Channel執行IO操做。

參考文檔

IO,BIO,AIO區別

TCP三次握手詳細介紹

Java堆和棧的區別

1）、堆和棧的共同點，

2）、堆和棧的區別，

3）、線程之間數據共享，

Java內存分兩類，一類是堆內存，一類是棧內存

堆：主要用於存儲實例化的對象，數組。由JVM動態分配內存空間。一個JVM只有一個堆內存，線程是能夠共享數據的。

棧：主要用於存儲局部變量和對象的引用變量，每一個線程都會有一個獨立的棧空間，因此線程之間是不共享數據的。

既然回答了內存，其實能夠把內存溢出的狀況一併回答。

談談內存溢出

1）、先回答什麼是內存溢出，

2）、再談談內存溢出的緣由，

3）、最後提出幾個內存溢出的解決方案，

內存溢出：程序運行實際使用的內存大於虛擬機設置的內存

溢出緣由：

1）、虛擬機配置參數設置不合理

2）、代碼中出現死循環或者產生大量的重複對象實體

3）、數據流若是沒有閉關也容易致使

4）、內存中一次性加載的數據量過於龐大

5）、大量的垃圾不能被JVM回收

解決方案：

1）、最直接，最不負責的方案就是修改JVM啓動參數

2）、正確流程是經過檢查錯誤日誌，查找OutOfMemory錯誤緣由，而後修改bug

JVM垃圾回收機制

1）、先回答什麼是JVM認爲的垃圾，

2）、都有那些經常使用的垃圾回收算法，

3）、都有那些經常使用的垃圾回收器，

JVM認爲那些不被使用的對象就是垃圾，須要從內存中除掉。

經常使用的垃圾回收算法有：引用計算法，標記清除法，標記壓縮法，複製算法，分代，分區思想

引用計算法：古老的算法，對象被引用時加一，引用斷開時減一，若爲零則被當成垃圾回收。頻繁加減操做性能低。

標記清除法：先把垃圾"標記"（遍歷全部的GC Roots，而後將全部GC Roots可達的對象標記爲存活的對象），後統一"清理"。清理後的內存空間不連續，性能不高。

標記壓縮法：在標記清除法的基礎上作一個壓縮功能。

複製算法：內存被分爲兩個大小相同的A，B兩塊，使用A內存時，將把A內存中的活對象複製到B，而後清空內存A中的全部對象。使用B內存也是同樣的。缺點是內存變小了。

分代思想：新生代，老年代（新生代中的對象通過頻繁的GC中存活下來的對象）。新生代由於存活率低，須要複製的對象少，建議用複製算法。老年代存活率高，須要清理的對象少，建議用標記壓縮法。

分區思想：將整個內存分爲多個獨立空間。在每一個獨立空間進行垃圾回收，提升系統性能。

串行垃圾回收器：使用單線程進行垃圾回收

並行垃圾回收器：使用多線程進行垃圾回收，對性能要求比較高

CMS收回器：併發回收器，比並行更快，當佔用的資源更多，能夠儘量減小系統停頓時間

G1回收器：JDK1.7以後提供的新的收集器，是基於標記壓縮的算法，特色是針對整個java堆進行

參考文檔：

JVM系列博客：https://blog.csdn.net/column/details/javavirtualmachine.html

lock和synchronized區別

1）、簡單介紹二者的區別

2）、工做中建議使用synchronized的緣由

3）、JDK1.6以後對synchronized的優化

synchronized：關鍵字，在jvm層面上，線程正常執行完後會釋放鎖，若線程發生異常則由jvm釋放鎖，jdk1.5以前沒有鎖競爭機制，容易出現線程一直阻塞的狀況，只適合少併發量使用。
Lock：類，必須在finally中釋放鎖，由於添加了鎖競爭機制，不會出現線程一直等待的問題，適合高併發量使用。

工做中建議使用synchronized關鍵字，緣由很簡單，jdk1.6以後對synchronized作了大量的優化。爲了減小得到鎖和釋放鎖所帶來的性能消耗，引入了「輕量級鎖」和「偏向鎖」來提升性能。

1、適應性自旋

下降了線程在等待鎖的過程當中的開銷。由於線程從掛起到恢復是很耗時的，有些線程在掛起後很短的時間內就能夠獲取鎖，經過漫無目的的循環讓線程暫不掛起。適應性自旋表如今自選的循環次數是根據實際狀況來定。

2、鎖消除

刪除一些不必的加鎖操做。

3、鎖粗化

雖然減少鎖的粒度，能夠提升性能。但有些代碼明明只須要加一把鎖，你非要加多個？？鎖粗化能夠把屢次加鎖和解鎖合併成一次，用以提升效率。

4、輕量級鎖

輕量級鎖所適應的場景是線程交替執行同步塊的狀況，若是存在同一時間訪問同一鎖的狀況，就會致使輕量級鎖膨脹爲重量級鎖。

5、偏向鎖

引入偏向鎖是爲了在無多線程競爭的狀況下儘可能減小沒必要要的輕量級鎖執行路徑，由於輕量級鎖的獲取及釋放依賴屢次CAS原子指令，而偏向鎖則是在只有一個線程執行同步塊時進一步提升性能。

參考文檔：

lock和synchronized區別：https://blog.csdn.net/wangtaomtk/article/details/52264043

lock和synchronized區別：https://blog.csdn.net/u012403290/article/details/64910926?locationNum=11&fps=1

HashMap底層實現

1）、簡單談談HashMap的底層實現

2）、HashMap和HashTable的區別

3）、工做中線程安全的HashMap使用

HashMap的底層是鏈表散列的數據結構，即數組和鏈表的結構。經過計算key的hash值肯定數組的位置，若該位置已經有值，則往該元素後面添加，造成一個鏈表。每一個Entity存儲hash，key，value，next四個值。在檢索中，經過hash找到數組的位置，而後在經過key遍歷鏈表，直到找到爲止。在jdk1.8之後，若鏈表長度超過闕值後，會將該鏈表轉爲紅黑樹，以提升檢索效率。紅黑樹是自平衡查找二叉樹，解決了二叉樹屢次插入新節點致使的不平衡。當紅黑樹插入新節點時會經過[變色]和[選擇]來知足自身規則，詳情能夠參考文檔鏈接。

HashMap，HashTable，LinkedHashMap區別

1）、HashMap不是線程安全的，HashTable是線程安全的，內部經過synchronized修改加鎖，其性能較差

2）、HashMap容許一個key爲null，HashTable不容許

3）、HashMap的初始容量是16，而HashTable的初始容量是11

4）、工做中HashMap的使用頻率較高，若但願值有序則使用LinkedHashMap，若考慮線程安全則使用ConcurrentHashMap，ConcurrentHashMap使用分段式鎖性能比HashTable好。

參考文檔：

ArrayList和LinkedList的區別，Java 經常使用List集合使用場景分析

HashMap的實現原理：https://blog.csdn.net/tuke_tuke/article/details/51588156

hashMap和hashTable的區別：https://www.cnblogs.com/aspirant/p/6856487.html

什麼是紅黑樹：http://www.sohu.com/a/201923614_466939

Java單例模式實現

1）、什麼是單例模式

2）、常見的單例模式有那些

3）、寫出其中的一種

單例模式：某個類只有一個實例，並且自行實例化並向整個系統提供這個實例。

常見的單例模式有：懶漢模式，餓漢模式，靜態類內部加載

// 線程安全的靜態類內部加載
public class SingletonDemo{
    private static class SingletonHolder{
        private static SingletonDemo instance = new SingletonDemo();
    }
    public static SingletonDemo getInstance() {
        return SingletonHolder.instance;
    }
}

參考文檔：

https://www.cnblogs.com/cielosun/p/6582333.html

談談MVC模式

聽到這個問題時，我是竊喜的，多麼簡單的問題，但是面試的時候，殊不知道該怎麼回答。

MVC：model，view，controller。

Model：模型層，負責實現業務邏輯，操做數據庫

View：視圖層，負責頁面展現

Controller：控制層，負責處理請求

咱們經過實際的框架來了解，

SpringMVC，它實現了mvc設計模式的web框架。用戶發送的請求會經過前端控制器（DispatcherServlet），根據URL映射到對應的Handler中。而這個Handler能夠是用註解@RequestMapping修飾的方法，而這個方法所在的類能夠用註解Controller修飾代表該類是一個控制層。能夠在方法裏面調用接口完成業務邏輯的操做和數據修改，將返回的結果放在ModelAndView變量中。DispatcherServlet會經過視圖解析器拼接返回頁面的路徑，並將數據放到做用域中，渲染給用戶。實現業務邏輯的接口能夠理解爲Model層，處理請求的類能夠理解爲Controller層，頁面就是View層。

談到SpringMVC，就不會少了Struts2，

Struts2也是一個基於MVC設計模式的Web應用框架，在web.xml文件中將符合要求的請求交給Servlet處理，這個 Servlet再參考struts-config.xml文件找到對應的action方法，執行完成後關聯到對應的頁面。SpringMVC比Struts2簡單了不少。

咱們再簡單談談Hibernate，Mybatis，SpringData

咱們還能夠再談談Spring

還有設計原理

偏應用的問題

由於時間和精力的狀況，這裏只作簡單整理的問題。

1、redis事務是怎麼作的？

答：redis的事務主要是經過multi（開啓事務），exec（提交事務），watch（監控版本號）幾個命令完成的。

2、如何實現搶購防超賣功能？

答：搶購，秒殺的場景下既要保證用戶體驗， 又要防超賣。其實很簡單，減小數據庫的調用，1000個商品限時搶購，就是1000個數字減一。經過加鎖保證線程安全。使用緩存提升效率。

3、如何設計數據查詢接口保證數據的安全和性能？

答：安全：服務器接口令牌驗證；查詢參數長度校驗；查詢參數格式校驗（避免sql注入）；

性能：索引優化；Ehcache本地緩存；redis緩存預熱；

4、Nginx如何作權限攔截？

答：Nginx和lua能夠實現權限攔截

5、2*16如何最快計算結果？

答：向左移動4位

6、架構如何用一個字段設置10個Boolean型權限？

答：用int型字段，分別用0，1表示false和true

七：爲何不用mysql作分佈式鎖？

答：我會從性能方面回答，用redis作分佈式鎖，是判斷key值是否存在，存在則表示有鎖。用Zookeeper作分佈式鎖，是判斷臨時節點是否存在，存在則表示有鎖。而mysql作分佈式鎖在併發量高的狀況下出現死鎖。

八：分佈式系統如何避免消息重複消費？

答：從生產者避免重複發送角度：將生產者發送的消息持久化到數據庫中，若有相同的信息則再也不保存；當生存者服務的事務完成後，消息服務會將數據庫中的消息發送給消費者。
從消費者避免重複消費角度：消費者服務多是集羣，要考慮冪等性。查詢和刪除是自然的冪操做，因此咱們要在更新和建立以前作判斷，是否已經存在，是否已經更新。

9、你對咱們公司的瞭解麼？
答：.......

先暫時到這裏，喜歡的朋友能夠關注我，以爲這篇文章對你有幫助也能夠點贊，若有問題，請儘快聯繫我，會及時修改。