【話題討論+送書福利】Java開發(fā)者如何跳出性能陷阱？

fenyun689

1. 你知道怎么樣的代碼可以幫助GC減負嗎？

寫簡單直觀的代碼，不要玩花招。過分設計、過多的封裝/抽象層，常常會讓GC很難受（導致需要處理的對象增多）。

要理解：GC是伙伴，不是仆人。在保持代碼結(jié)構(gòu)良好、直觀易懂的前提下，減少沒必要的對象分配總是好的。

不要調(diào)用System.gc() <- 可能影響GC的統(tǒng)計數(shù)據(jù)和未來決策.

不要隨意使用“對象池” <- 為了優(yōu)化GC而使用對象池常常是非常有害的。為了別的有用的目的，例如說持有初始化開銷高的資源而使用對象池，這才是通常可取的場景。

通常不用關(guān)心對局部變量置null

小心使用ThreadLocal，特別是當跟線程池搭配使用的時候 <- 如果用線程池來跑任務，而這些任務向ThreadLocal寫入了數(shù)據(jù)，那么應該注意在任務完成時清理ThreadLocal，不然容易泄漏

如果使用堆外內(nèi)存來實現(xiàn)Java對象的緩存，而且在堆外內(nèi)存里存的是序列化后的Java對象的話，要小心使用時的反序列化開銷及其伴隨的頻繁創(chuàng)建對象的開銷。




2. 程序內(nèi)存溢出了，應該怎么辦？我們應該怎樣寫代碼，才能更好的幫助程序在出問題時，盡快定位問題？

JVM運行時首先需要類加載器（classLoader）加載所需類的字節(jié)碼文件。加載完畢交由執(zhí)行引擎執(zhí)行，在執(zhí)行過程中需要一段空間來存儲數(shù)據(jù)（類比CPU與主存）。這段內(nèi)存空間的分配和釋放過程正是我們需要關(guān)心的運行時數(shù)據(jù)區(qū)。內(nèi)存溢出的情況就是從類加載器加載的時候開始出現(xiàn)的，內(nèi)存溢出分為兩大類：OutOfMemoryError和StackOverflowError。以下舉出內(nèi)存溢出的情況。
1、java堆內(nèi)存溢出。2、java堆內(nèi)存泄漏。3、垃圾回收超時內(nèi)存溢出。4、Metaspace內(nèi)存溢出。5、直接內(nèi)存內(nèi)存溢出。6、創(chuàng)建本地線程內(nèi)存溢出。7、超出交換區(qū)內(nèi)存溢出。8、超出交換區(qū)內(nèi)存溢出。

3. 多線程編程總能提高程序性能嗎？使用時需要注意什么  ？
不一定。主要有兩個方面，一方面是線程調(diào)度，另一個方面是線程協(xié)作。

首先，我們看一下線程調(diào)度，在實際開發(fā)中，線程數(shù)往往是大于 CPU 核心數(shù)的，比如 CPU 核心數(shù)可能是 8 核、16 核，等等，但線程數(shù)可能達到成百上千個。這種情況下，操作系統(tǒng)就會按照一定的調(diào)度算法，給每個線程分配時間片，讓每個線程都有機會得到運行。而在進行調(diào)度時就會引起上下文切換，上下文切換會掛起當前正在執(zhí)行的線程并保存當前的狀態(tài)，然后尋找下一處即將恢復執(zhí)行的代碼，**下一個線程，以此類推，反復執(zhí)行。但上下文切換帶來的開銷是比較大的，假設我們的任務內(nèi)容非常短，比如只進行簡單的計算，那么就有可能發(fā)生我們上下文切換帶來的性能開銷比執(zhí)行線程本身內(nèi)容帶來的開銷還要大的情況。

不僅上下文切換會帶來性能問題，緩存失效也有可能帶來性能問題。由于程序有很大概率會再次訪問剛才訪問過的數(shù)據(jù)，所以為了加速整個程序的運行，會使用緩存，這樣我們在使用相同數(shù)據(jù)時就可以很快地獲取數(shù)據(jù)�？梢坏┻M行了線程調(diào)度，切換到其他線程，CPU就會去執(zhí)行不同的代碼，原有的緩存就很可能失效了，需要重新緩存新的數(shù)據(jù)，這也會造成一定的開銷，所以線程調(diào)度器為了避免頻繁地發(fā)生上下文切換，通常會給被調(diào)度到的線程設置最小的執(zhí)行時間，也就是只有執(zhí)行完這段時間之后，才可能進行下一次的調(diào)度，由此減少上下文切換的次數(shù)。
那么什么情況會導致密集的上下文切換呢？如果程序頻繁地競爭鎖，或者由于 IO 讀寫等原因?qū)е骂l繁阻塞，那么這個程序就可能需要更多的上下文切換，這也就導致了更大的開銷，我們應該盡量避免這種情況的發(fā)生。

除了線程調(diào)度之外，線程協(xié)作同樣也有可能帶來性能問題。因為線程之間如果有共享數(shù)據(jù)，為了避免數(shù)據(jù)錯亂，為了保證線程安全，就有可能禁止編譯器和 CPU 對其進行重排序等優(yōu)化，也可能出于同步的目的，反復把線程工作內(nèi)存的數(shù)據(jù) flush 到主存中，然后再從主內(nèi)存 refresh 到其他線程的工作內(nèi)存中，等等。這些問題在單線程中并不存在，但在多線程中為了確保數(shù)據(jù)的正確性，就不得不采取上述方法，因為線程安全的優(yōu)先級要比性能優(yōu)先級更高，這也間接降低了我們的性能。

jieforest

1. 你知道怎么樣的代碼可以幫助GC減負嗎？
這話題有點大。
總的來說，要想GC的負擔最小，那么編程就應該遵循Java的最佳實踐，這樣寫出來的代碼在JVM上運行時，GC的負擔最小。故問題可歸納為Java編程的最佳實踐。
下面列出一些Java編程的最佳實踐：
1）遵循Java的命名約定
2）類的成員變量應該使用private
3）不要省略catch語句塊中的代碼
4）使用StringBuilder或StringBuffer來代替String字符串的連結(jié)操作
5）使用枚舉類或常量類來代替常量接口
6）避免冗余初始化（0-false-null）
7）在類中，像0、false或null這些值，原本就是String、int、boolean類型的默認初始值。故如果初始值為0、false或null，無需做初始化。
8）在使用集合的場景，最好使用對集合的接口引用
9）不要在索引（或計數(shù)器）變量中使用for循環(huán)
以上僅僅列舉了一些常見的最佳實踐，實際上Java編程的最佳實踐非常多，比如單元測試的最佳實踐，JDBC的最佳實踐，Java異常處理的最佳實踐，Spring框架使用的最佳實踐......
一個Java項目，把所有的部分都進行調(diào)優(yōu)，比如設計調(diào)優(yōu)、代碼調(diào)優(yōu)、模塊調(diào)優(yōu)、JVM調(diào)優(yōu)、數(shù)據(jù)庫調(diào)優(yōu)，最終得到的項目源碼，GC的負擔肯定最小。

2. 程序內(nèi)存溢出了，應該怎么辦？我們應該怎樣寫代碼，才能更好的幫助程序在出問題時，盡快定位問題？
JVM管理兩種類型的內(nèi)存，堆和非堆。
如果是堆內(nèi)存溢出，即java.lang.OutOfMemoryError: Java heap space，最簡單的解決方法是調(diào)整Xmx參數(shù)，把值改大一些。如果這樣還解決不了問題，使用工具去定位內(nèi)存泄露。
如果是非堆內(nèi)存溢出，即java.lang.OutOfMemoryError: PermGen space。在啟動Java程序時調(diào)整-XXermSize和-XX:MaxPermSize兩個參數(shù)，把值改大一些。
另外還有元空間的內(nèi)存溢出，即java.lang.OutOfMemoryError: Metaspace。遇到此問題，可以在啟動Java程序時調(diào)整-XX:MetaspaceSize和-XX:MaxMetaspaceSize參數(shù)來解決。
除了以上情況，或許還可能會遇到交換區(qū)內(nèi)存溢出、棧內(nèi)存溢出等問題。遇到這些問題具體情況具體分析。

3. 多線程編程總能提高程序性能嗎？使用時需要注意什么？
Java的線程與CPU內(nèi)核數(shù)緊密相關(guān)，故Java在多線程編程時要特別注意項目的最終運行環(huán)境，即生產(chǎn)環(huán)境的CPU內(nèi)核數(shù)。多線程編程能提高性能是確定無疑的，但線程并非越多越好，線程切換帶來的開銷不可小視，要注意線程數(shù)跟生產(chǎn)環(huán)境的CPU內(nèi)核數(shù)相匹配。

forgaoqiang

先占個坑吧 最近也跳到Java技術(shù)棧上研究一段時間，回頭發(fā)表下自己的拙見，分為兩個部分吧，第一個部分關(guān)于圖書的試讀章節(jié)，第二部分關(guān)于提出的問題
PART1：
試讀章節(jié)包含了圖書的完整的第一章和第二章節(jié)的2.2小節(jié)的部分，總共44頁
第一章節(jié)是一個通用性的描述，關(guān)于Java性能調(diào)優(yōu)的概述：
第一章提供的基本的思路和方法，首先進行了性能概述：
1）什么是性能，舉例出常見的Eclipse IDE的卡死問題，這就是性能問題。
2）評價性能的參數(shù)，比如執(zhí)行時間、占用CPU時間、內(nèi)存使用、磁盤I/O使用、網(wǎng)絡使用以及響應時間等。
3）木桶原理和性能瓶頸，將上面中的各個參數(shù)單獨拿出來說，表明程序會因為某一個短板導致整體性能下降。
4）Amdahl定律，阿姆達爾定律是一個計算機科學界的經(jīng)驗法則，因吉恩·阿姆達爾而得名。它代表了處理器并行運算之后效率提升的能力，特別強調(diào)僅僅增加核心不一定能夠起到有效作用。
5）性能調(diào)優(yōu)不同層次上的方法，比如在設計角度上調(diào)優(yōu)、代碼上的調(diào)優(yōu)（好的實現(xiàn)）、JVM（Java虛擬機）上面的調(diào)優(yōu)，JVM層次需要程序員對JVM工作原理有所了解，以便寫出對對JVM友好的代碼、還有用到的持久化存儲數(shù)據(jù)庫上的調(diào)優(yōu)、甚至包括運行JVM的OS的操作系統(tǒng)調(diào)優(yōu)等層次。
6）基本策略和手段，首先要有策略和目標，然后在對著目標進行。

第二章節(jié)開始細化講解上面的設計角度上的調(diào)優(yōu)，畢竟優(yōu)秀的設計能夠規(guī)避掉很多的潛在的性能上的問題，重點開始講解 設計模式（Design Pattern）
1）單例模式，他是一種對象創(chuàng)建模式，只產(chǎn)生一個對象的具體實例，這樣可以省去每次New一個新對象的開銷，同時減少GC時間。
2）代理模式，代理對象完成用戶的請求，屏蔽掉用戶對真實對象的直接訪問，很多時候通過對真實的對象進行封裝，可以打到延遲加載的目的�！�延遲加載可以在真正使用組件的時候才初始化它，有效的節(jié)約資源】
3）享元模式，這個模式主要的設計目的就是為了提升性能，核心思想是：系統(tǒng)中有多個相同的對象時，只需要對象的一份拷貝即可，不需要每次使用都創(chuàng)建新的對象，會使用工廠類創(chuàng)建。是不是聽起來和單例模式很像，但是要注意主要區(qū)別 享元設計模式是一個類有很多對象，而單例是一個類僅一個對象。
4）裝飾者模式，我們一直在講代碼復用，那么裝飾者模式就是這么做的，繼承是緊密的耦合，委托是松散的耦合，裝飾者模式就是復用系統(tǒng)中各個組件，運行時將這些組件進行疊加，說到這里就要提下 midway這些nodejs框架，本身提供裝飾器，那么下面是使用KOA還是express都可以支持。
5）觀察者模式，一個對象依賴另一個對象狀態(tài)時，就可以使用。在編程思想中，這種 狀態(tài)機 的編程方式，在大量系統(tǒng)中使用。
6）值對象模式，這個是比較復雜的一種用法，之前并沒有用到過，看描述是將對象的各個屬性進行封裝，然后傳遞整個對象，是系統(tǒng)擁有更好的交互模型，減少網(wǎng)絡通信次數(shù)來減少網(wǎng)絡流量，提高系統(tǒng)的性能。
7）業(yè)務代理模式，和值對象的方式類似，將一組遠程調(diào)用的業(yè)務流程封裝在一個位于展示層的代理類中，.... 說實話，作為Java的菜鳥，這個方式并沒有真正理解
常用優(yōu)化組件和方法：
緩沖和緩存（Buffer和Cache），試讀章節(jié)就此打住，┭┮﹏┭┮


PART II：

1. 你知道怎么樣的代碼可以幫助GC減負嗎？
Java語言的一大特性之一就是提供垃圾回收GC機制，Java程序員可以任意的創(chuàng)建對象和使用內(nèi)存而無需對內(nèi)存回收做顯示的工作。如果要對GC減負，基本方法就是兩個維度，1）減少不必要的對象創(chuàng)建 2）編寫GC友好的代碼
正如試讀章節(jié)中講到的，合理的設計模式就可以提高性能，比如上面提到的采用單例模式以及享元模式，都可以有效的降低內(nèi)存占用，從而減少被回收對象的數(shù)量。
Java不同版本采用GC方式也不相同，包括標記刪除、G1GC、ZGC。
減負的方法如下:
1）使用更多短生命周期的和體積小的對象，并且對象不改變指向。
2）避免顯示的System.gc（）方法調(diào)用，交給GC可以更有效的左整體規(guī)劃垃圾回收。
3）采用弱引用等方法

2. 程序內(nèi)存溢出了，應該怎么辦？我們應該怎樣寫代碼，才能更好的幫助程序在出問題時，盡快定位問題？
內(nèi)存移除基本上是發(fā)生了內(nèi)存泄露導致的，如果純粹的物理機器無法滿足內(nèi)存需求那另當別論，應該盡量使用try catch的方法，在關(guān)鍵節(jié)點和容易出問題的代碼上做異常處理，出現(xiàn)問題也容易定位。
對于內(nèi)存泄露，也有工具比如 Memory Analyzer Tool 可以進行分析，正如C語言常用的內(nèi)存泄露分析工具valgrind一樣，可以給出很多關(guān)鍵的信息，特別容易看出來哪一段代碼會有內(nèi)存泄露現(xiàn)象。


3. 多線程編程總能提高程序性能嗎？使用時需要注意什么  ？

多線程不一定提升性能，尤其是單核心處理器的場景，多線程可能會增加開銷，NodeJS即使單線程也能做到極高的性能，主要是異步的功效。
多線程編程如果線程之間無需操作共享變量，那么多線程是安全的，如果需要共同操作公有資源，就要注意并發(fā)和鎖，避免出現(xiàn)不一致的問題。