性能面試題

1. JVM工做原理： JVM是Java程序運行的平臺，它就像一臺虛擬出來的計算機同樣，負責執行Java編譯好的字節碼文件。JVM具備很是嚴格的實現規範，大多數操做系統均可以安裝JVM，爲Java語言的跨平臺性起到了關鍵的做用。

 

2. JVM垃圾回收原理：垃圾回收器會全程偵測Java應用程序的運行狀況。當發現有些對象成爲垃圾時，垃圾回收器就會銷燬這些對象，並釋放這些對象所佔用的內存空間。（NULL值賦給相關對象和對象超出做用範圍，可認爲是垃圾）

 

3. JVM堆棧構成：堆(Heap)主要用來存放對象的，棧(Stack)主要是用來執行程序的.JVM是基於堆棧的虛擬機.JVM爲每一個新建立的線程都分配一個堆棧.也就是說,對於一個Java程序來講，它的運行就是經過對堆棧的操做來完成的。堆棧以幀爲單位保存線程的狀態。JVM對堆棧只進行兩種操做:以幀爲單位的壓棧和出棧操做。

 

4. JVM的內存管理：JVM中的內存管理主要是指JVM對於Heap的管理，這是由於Stack，PCRegister和NativeMethodStack都是和線程同樣的生命週期，在線程結束時天然能夠被再次使用

 

5. 內存泄露和內存溢出產生的緣由和結果：

　　內存泄露(memory leak)是指你向系統申請分配內存進行使用(new)，但是使用完了之後卻不歸還(delete)，結果你申請到的那塊內存你本身也不能再訪問（也許你把它的地址給弄丟了），而系統也不能再次將它分配給須要的程序。

　　內存溢出(out of memory)就是你要求分配的內存超出了系統能給你的，系統不能知足需求，因而產生溢出。

　　從用戶使用程序的角度來看，內存泄漏自己不會產生什麼危害，做爲通常的用戶，根本感受不到內存泄漏的存在。真正有危害的是內存泄漏的堆積，這會最終消耗盡系統全部的內存。memory leak會最終會致使out of memory！

 

　　內存溢出的緣由以及解決方法：

　　1.內存中加載的數據量過於龐大，如一次從數據庫取出過多數據；

　　2.集合類中有對對象的引用，使用完後未清空，使得JVM不能回收；

　　3.代碼中存在死循環或循環產生過多重複的對象實體；

　　4.使用的第三方軟件中的BUG；

　　5.啓動參數內存值設定的太小

　　解決辦法：

　　第一步，修改JVM啓動參數，直接增長內存。(-Xms，-Xmx參數必定不要忘記加。)

　　第二步，檢查錯誤日誌，查看「OutOfMemory」錯誤前是否有其它異常或錯誤。

　　第三步，對代碼進行走查和分析，找出可能發生內存溢出的位置。

　　重點排查如下幾點：

　　　　1.檢查對數據庫查詢中，是否有一次得到所有數據的查詢。建議使用分頁執行查詢。

　　　　2.檢查代碼中是否有死循環或遞歸調用。

　　　　3.檢查是否有大循環重複產生新對象實體。

　　　　4. 檢查List、MAP等集合對象是否有使用完後，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。

　　第四步，使用內存查看工具動態查看內存使用狀況

6. Java開發中會遇到的性能問題：

　　A. OOM內存不足：1. 不斷地申請對象，後面對象申請不到內存資源（調整對象大小或擴容）；2. 持續地啓線程，申請棧資源，形成內存不足（調整每一個線程的堆棧大小Xss=256或者擴容）3. 頻繁地觸發FULL GC，形成OOM(調整新生代GC大小或下降GC的執行次數)

　　B. 內存泄露：對象和線程等一直不釋放資源，致使內存泄露(釋放沒必要要的引用、使用對象緩存池、採用合理的緩存失效算法、合理使用SoftReference和WeekReference：SoftReference的對象會在內存不夠用的時候回收，WeekReference的對象會在Full GC的時候回收)

　　C. 線程死鎖：兩個線程佔用不一樣的資源不釋放，形成線程死鎖（規定資源執行順序，可是也會形成鎖飢餓，解決辦法是減短鎖釋放時間）

　　D. 鎖爭用：不少線程競爭互斥資源，但資源有限， 形成其餘線程都處於等待狀態（使用非阻塞隊列算法、拆分鎖，去除讀寫操做的互斥，儘量少用鎖）

　　E. 堆棧資源不足：線程嵌套式地申請堆棧資源，致使堆棧資源不足（調整堆棧大小）

　　F. Java進程消耗CPU太高：1. us高：執行線程不須要任何掛起動做，且一直執行，致使CPU 沒有機會去調度執行其餘的線程。（增長Thread.sleep，以釋放CPU 的執行權，下降CPU 的消耗）；2. sy高：線程的運行狀態要常常切換（下降線程數） 

　　G. 文件IO消耗嚴重：多個線程在寫進行大量的數據到同一文件，致使文件很快變得很大，從而寫入速度愈來愈慢，並形成各線程激烈爭搶文件鎖。（異步寫文件、批量讀寫、限流、限制文件大小）

　　H. 網絡IO消耗嚴重: 同時須要發送或接收的包太多。(限流，限流一般是限制發送packet的頻率，從而在網絡IO消耗可接受的狀況下來發送packget。)

6. 性能瓶頸分析：

　　查找瓶頸時按如下順序，由易到難：服務器硬件瓶頸-〉網絡瓶頸（對局域網，能夠不考慮）-〉服務器操做系統瓶頸（參數配置）-〉中間件瓶頸（參數配置，數據庫，web服務器等）-〉應用瓶頸（SQL語句、數據庫設計、業務邏輯、算法等）