文章很長，建議收藏起來，慢慢讀！ Java 高並發 發燒友社群：瘋狂創客圈 奉上以下珍貴的學習資源：
-
免費贈送 經典圖書:《Java高並發核心編程（卷1）》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 經典圖書:《Java高並發核心編程（卷2）》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 經典圖書:《Netty Zookeeper Redis 高並發實戰》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 經典圖書:《SpringCloud Nginx高並發核心編程》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
-
免費贈送 資源寶庫： Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取
推薦： 瘋狂創客圈 高質量 博文
| 高並發 必讀 的精彩博文 | |
|---|---|
| nacos 實戰（史上最全） | sentinel （史上最全+入門教程） |
| Zookeeper 分布式鎖 （圖解+秒懂+史上最全） | Webflux（史上最全） |
| SpringCloud gateway （史上最全） | TCP/IP（圖解+秒懂+史上最全） |
| 10分鍾看懂， Java NIO 底層原理 | Feign原理 （圖解） |
| 更多精彩博文 ..... | 請參見【 瘋狂創客圈 高並發 總目錄 】 |
史上最全 Java 面試題 30 專題 總目錄
內存泄漏和內存溢出
內存溢出和內存泄露的區別與聯系
內存溢出：（out of memory）通俗理解就是內存不夠，指程序要求的內存超出了系統所能分配的范圍，通常在運行大型軟件或游戲時，軟件或游戲所需要的內存遠遠超出了你主機內安裝的內存所承受大小，就叫內存溢出。比如申請一個int類型，但給了它一個int才能存放的數，就會出現內存溢出，或者是創建一個大的對象，而堆內存放不下這個對象，這也是內存溢出。
內存泄漏：（Memory Leak）是指程序中己動態分配的堆內存由於某種原因程序未釋放或無法釋放，造成系統內存的浪費，導致程序運行速度減慢甚至系統崩潰等嚴重后果。一次內存泄露危害可以忽略，但內存泄露堆積后果很嚴重，無論多少內存,遲早會被占光。
因此，我們從上面也可以推斷出內存泄露可能會導致內存溢出。
二者的關系：
內存溢出會拋出異常，內存泄露不會拋出異常，大多數時候程序看起來是正常運行的。
JVM內存模型
根據 JVM8 規范，JVM 運行時內存共分為虛擬機棧、堆、元空間、程序計數器、本地方法棧五個部分。還有一部分內存叫直接內存，屬於操作系統的本地內存，也是可以直接操作的。
- 元空間(Metaspace）
元空間的本質和永久代類似，都是對JVM規范中方法區的實現。不過元空間與永久代之間最大的區別在於：元空間並不在虛擬機中，而是使用本地內存。
2.虛擬機棧(JVM Stacks）
每個線程有一個私有的棧，隨着線程的創建而創建。棧里面存着的是一種叫“棧幀”的東西，每個方法會創建一個棧幀，棧幀中存放了局部變量表（基本數據類型和對象引用）、操作數棧、方法出口等信息。棧的大小可以固定也可以動態擴展。
- 本地方法棧(Native Method Stack)
與虛擬機棧類似，區別是虛擬機棧執行java方法，本地方法站執行native方法。在虛擬機規范中對本地方法棧中方法使用的語言、使用方法與數據結構沒有強制規定，因此虛擬機可以自由實現它。
- 程序計數器(Program Counter Register)
程序計數器可以看成是當前線程所執行的字節碼的行號指示器。在任何一個確定的時刻，一個處理器（對於多內核來說是一個內核）都只會執行一條線程中的指令。因此，為了線程切換后能恢復到正確的執行位置，每條線程都需要一個獨立的程序計數器，我們稱這類內存區域為“線程私有”內存。
5.堆內存(Heap)
堆內存是 JVM 所有線程共享的部分，在虛擬機啟動的時候就已經創建。所有的對象和數組都在堆上進行分配。這部分空間可通過 GC 進行回收。當申請不到空間時會拋出 OutOfMemoryError。堆是JVM內存占用最大，管理最復雜的一個區域。其唯一的用途就是存放對象實例：所有的對象實例及數組都在對上進行分配。jdk1.8后，字符串常量池從永久代中剝離出來，存放在隊中。
6.直接內存(Direct Memory)
直接內存並不是虛擬機運行時數據區的一部分，也不是Java 虛擬機規范中農定義的內存區域。在JDK1.4 中新加入了NIO(New Input/Output)類，引入了一種基於通道(Channel)與緩沖區（Buffer）的I/O 方式，它可以使用native 函數庫直接分配堆外內存，然后通脫一個存儲在Java堆中的DirectByteBuffer 對象作為這塊內存的引用進行操作。這樣能在一些場景中顯著提高性能，因為避免了在Java堆和Native堆中來回復制數據。
內存泄露8種情況
由於java的JVM引入了垃圾回收機制，垃圾回收器會自動回收不再使用的對象，了解JVM回收機制的都知道JVM是使用引用計數法和可達性分析算法來判斷對象是否是不再使用的對象，本質都是判斷一個對象是否還被引用。那么對於這種情況下，由於代碼的實現不同就會出現很多種內存泄漏問題（讓JVM誤以為此對象還在引用中，無法回收，造成內存泄漏）。
1、靜態集合類
如HashMap、LinkedList等等。如果這些容器為靜態的，那么它們的生命周期與程序一致，則容器中的對象在程序結束之前將不能被釋放，從而造成內存泄漏。簡單而言，長生命周期的對象持有短生命周期對象的引用，盡管短生命周期的對象不再使用，但是因為長生命周期對象持有它的引用而導致不能被回收。
2、各種連接，如數據庫連接、網絡連接和IO連接等。
在對數據庫進行操作的過程中，首先需要建立與數據庫的連接，當不再使用時，需要調用close方法來釋放與數據庫的連接。只有連接被關閉后，垃圾回收器才會回收對應的對象。否則，如果在訪問數據庫的過程中，對Connection、Statement或ResultSet不顯性地關閉，將會造成大量的對象無法被回收，從而引起內存泄漏。
3、變量不合理的作用域。
一般而言，一個變量的定義的作用范圍大於其使用范圍，很有可能會造成內存泄漏。另一方面，如果沒有及時地把對象設置為null，很有可能導致內存泄漏的發生。
public class UsingRandom {
private String msg;
public void receiveMsg(){
readFromNet();// 從網絡中接受數據保存到msg中
saveDB();// 把msg保存到數據庫中
}
}
123456789101112131415
如上面這個偽代碼，通過readFromNet方法把接受的消息保存在變量msg中，然后調用saveDB方法把msg的內容保存到數據庫中，此時msg已經就沒用了，由於msg的生命周期與對象的生命周期相同，此時msg還不能回收，因此造成了內存泄漏。
實際上這個msg變量可以放在receiveMsg方法內部，當方法使用完，那么msg的生命周期也就結束，此時就可以回收了。還有一種方法，在使用完msg后，把msg設置為null，這樣垃圾回收器也會回收msg的內存空間。
4、內部類持有外部類
如果一個外部類的實例對象的方法返回了一個內部類的實例對象，這個內部類對象被長期引用了，即使那個外部類實例對象不再被使用，但由於內部類持有外部類的實例對象，這個外部類對象將不會被垃圾回收，這也會造成內存泄露。
5、改變哈希值
當一個對象被存儲進HashSet集合中以后，就不能修改這個對象中的那些參與計算哈希值的字段了，否則，對象修改后的哈希值與最初存儲進HashSet集合中時的哈希值就不同了，在這種情況下，即使在contains方法使用該對象的當前引用作為的參數去HashSet集合中檢索對象，也將返回找不到對象的結果，這也會導致無法從HashSet集合中單獨刪除當前對象，造成內存泄露
6、過期引用
內存泄漏的第一個常見來源是存在過期引用。
舉個例子-看你能否找出內存泄漏
import java.util.Arrays;
public class Stack {
private Object[] elements;
private int size = 0;
private static final int DEFAULT_INITIAL_CAPACITY = 16;
public Stack() {
elements = new Object[DEFAULT_INITIAL_CAPACITY];
}
public void push(Object e) {
ensureCapacity();
elements[size++] = e;
}
public Object pop() {
if (size == 0)
throw new EmptyStackException();
return elements[--size];
}
private void ensureCapacity() {
if (elements.length == size)
elements = Arrays.copyOf(elements, 2 * size + 1);
}
}
1234567891011121314151617181920212223242526272829
如果一個棧先是增長，然后再收縮，從棧中彈出來的對象不會被當作垃圾回收，即使使用棧的程序不再引用這些對象，它們也不會被回收。因為棧內部維護着對這些對象的過期引用（obsolete reference）。過期引用指永遠也不會再被解除的引用。在本例中，在elements數組的“活動部分（active portion）”之外的任何引用都是過期的。活動部分指elements中下標小於size的那些元素。
如果一個對象引用被無意識地保留了，垃圾回收機制不僅不會回收這個對象，而且不會回收被這個對象所引用的所有其他對象。解決方法：一旦對象引用已經過期，只需清空這些引用即可。在本例中，只要一個元素被彈出棧，指向它的引用就過期了。
6.1原因分析
上述程序並沒有明顯的錯誤，但是這段程序有一個內存泄漏，隨着GC活動的增加，或者內存占用的不斷增加，程序性能的降低就會表現出來，嚴重時可導致內存泄漏，但是這種失敗情況相對較少。
代碼的主要問題在pop函數，下面通過這張圖示展現
假設這個棧一直增長，增長后如下圖所示
當進行大量的pop操作時，由於引用未進行置空，gc是不會釋放的，如下圖所示
從上圖中看以看出，如果棧先增長，在收縮，那么從棧中彈出的對象將不會被當作垃圾回收，即使程序不再使用棧中的這些隊象，他們也不會回收，因為棧中仍然保存這對象的引用，俗稱過期引用，這個內存泄露很隱蔽。
6.2解決方法
public Object pop() {
if (size == 0)
throw new EmptyStackException();
Object result = elements[--size];
elements[size] = null;
return result;
}
1234567
一旦引用過期，清空這些引用，將引用置空。
7.緩存泄漏
內存泄漏的另一個常見來源是緩存，一旦你把對象引用放入到緩存中，他就很容易遺忘，對於這個問題，可以使用WeakHashMap代表緩存，此種Map的特點是，當除了自身有對key的引用外，此key沒有其他引用那么此map會自動丟棄此值
7.1代碼示例
package com.ratel.test;
/**
* @業務描述：
* @package_name： com.ratel.test
* @project_name： ssm
* @author： ratelfu@qq.com
* @create_time： 2019-04-18 20:20
* @copyright (c) ratelfu 版權所有
*/
import java.util.HashMap;
import java.util.Map;
import java.util.WeakHashMap;
import java.util.concurrent.TimeUnit;
public class MapTest {
static Map wMap = new WeakHashMap();
static Map map = new HashMap();
public static void main(String[] args) {
init();
testWeakHashMap();
testHashMap();
}
public static void init(){
String ref1= new String("obejct1");
String ref2 = new String("obejct2");
String ref3 = new String ("obejct3");
String ref4 = new String ("obejct4");
wMap.put(ref1, "chaheObject1");
wMap.put(ref2, "chaheObject2");
map.put(ref3, "chaheObject3");
map.put(ref4, "chaheObject4");
System.out.println("String引用ref1，ref2，ref3，ref4 消失");
}
public static void testWeakHashMap(){
System.out.println("WeakHashMap GC之前");
for (Object o : wMap.entrySet()) {
System.out.println(o);
}
try {
System.gc();
TimeUnit.SECONDS.sleep(20);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("WeakHashMap GC之后");
for (Object o : wMap.entrySet()) {
System.out.println(o);
}
}
public static void testHashMap(){
System.out.println("HashMap GC之前");
for (Object o : map.entrySet()) {
System.out.println(o);
}
try {
System.gc();
TimeUnit.SECONDS.sleep(20);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
System.out.println("HashMap GC之后");
for (Object o : map.entrySet()) {
System.out.println(o);
}
}
}
/** 結果
String引用ref1，ref2，ref3，ref4 消失
WeakHashMap GC之前
obejct2=chaheObject2
obejct1=chaheObject1
WeakHashMap GC之后
HashMap GC之前
obejct4=chaheObject4
obejct3=chaheObject3
Disconnected from the target VM, address: '127.0.0.1:51628', transport: 'socket'
HashMap GC之后
obejct4=chaheObject4
obejct3=chaheObject3
**/
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990
上面代碼和圖示主演演示WeakHashMap如何自動釋放緩存對象，當init函數執行完成后，局部變量字符串引用weakd1,weakd2,d1,d2都會消失，此時只有靜態map中保存中對字符串對象的引用，可以看到，調用gc之后，hashmap的沒有被回收，而WeakHashmap里面的緩存被回收了。
8.監聽器和回調
內存泄漏第三個常見來源是監聽器和其他回調，如果客戶端在你實現的API中注冊回調，卻沒有顯示的取消，那么就會積聚。需要確保回調立即被當作垃圾回收的最佳方法是只保存他的若引用，例如將他們保存成為WeakHashMap中的鍵。
內存溢出的十個場景
JVM運行時首先需要類加載器（classLoader）加載所需類的字節碼文件。加載完畢交由執行引擎執行，在執行過程中需要一段空間來存儲數據（類比CPU與主存）。這段內存空間的分配和釋放過程正是我們需要關心的運行時數據區。內存溢出的情況就是從類加載器加載的時候開始出現的，內存溢出分為兩大類：OutOfMemoryError和StackOverflowError。以下舉出10個內存溢出的情況，並通過實例代碼的方式講解了是如何出現內存溢出的。
1.java堆內存溢出
當出現java.lang.OutOfMemoryError:Java heap space異常時，就是堆內存溢出了。
1.問題描述
1.設置的jvm內存太小，對象所需內存太大，創建對象時分配空間，就會拋出這個異常。
2.流量/數據峰值，應用程序自身的處理存在一定的限額，比如一定數量的用戶或一定數量的數據。而當用戶數量或數據量突然激增並超過預期的閾值時，那么就會峰值停止前正常運行的操作將停止並觸發java . lang.OutOfMemoryError:Java堆空間錯誤
2.示例代碼
編譯以下代碼，執行時jvm參數設置為-Xms20m -Xmx20m
以上這個示例，如果一次請求只分配一次5m的內存的話，請求量很少垃圾回收正常就不會出錯，但是一旦並發上來就會超出最大內存值，就會拋出內存溢出。
3.解決方法
首先，如果代碼沒有什么問題的情況下，可以適當調整-Xms和-Xmx兩個jvm參數，使用壓力測試來調整這兩個參數達到最優值。
其次，盡量避免大的對象的申請，像文件上傳，大批量從數據庫中獲取，這是需要避免的，盡量分塊或者分批處理，有助於系統的正常穩定的執行。
最后，盡量提高一次請求的執行速度，垃圾回收越早越好，否則，大量的並發來了的時候，再來新的請求就無法分配內存了，就容易造成系統的雪崩。
2.java堆內存泄漏
1.問題描述
Java中的內存泄漏是一些對象不再被應用程序使用但垃圾收集無法識別的情況。因此，這些未使用的對象仍然在Java堆空間中無限期地存在。不停的堆積最終會觸發java . lang.OutOfMemoryError。
2.示例代碼
當執行上面的代碼時，可能會期望它永遠運行，不會出現任何問題，假設單純的緩存解決方案只將底層映射擴展到10,000個元素，而不是所有鍵都已經在HashMap中。然而事實上元素將繼續被添加，因為key類並沒有重寫它的equals()方法。
隨着時間的推移，隨着不斷使用的泄漏代碼，“緩存”的結果最終會消耗大量Java堆空間。當泄漏內存填充堆區域中的所有可用內存時，垃圾收集無法清理它，java . lang.OutOfMemoryError。
3.解決辦法
相對來說對應的解決方案比較簡單：重寫equals方法即可：
3.垃圾回收超時內存溢出
1、問題描述
當應用程序耗盡所有可用內存時，GC開銷限制超過了錯誤，而GC多次未能清除它，這時便會引發java.lang.OutOfMemoryError。當JVM花費大量的時間執行GC，而收效甚微，而一旦整個GC的過程超過限制便會觸發錯誤(默認的jvm配置GC的時間超過98%，回收堆內存低於2%)。
2.示例代碼
3.解決方法
要減少對象生命周期，盡量能快速的進行垃圾回收。
4.Metaspace內存溢出
1.問題描述
元空間的溢出，系統會拋出java.lang.OutOfMemoryError: Metaspace。出現這個異常的問題的原因是系統的代碼非常多或引用的第三方包非常多或者通過動態代碼生成類加載等方法，導致元空間的內存占用很大。
2.示例代碼
以下是用循環動態生成class的方式來模擬元空間的內存溢出的。
3.解決辦法
默認情況下，元空間的大小僅受本地內存限制。但是為了整機的性能，盡量還是要對該項進行設置，以免造成整機的服務停機。
1）優化參數配置，避免影響其他JVM進程
-XX:MetaspaceSize，初始空間大小，達到該值就會觸發垃圾收集進行類型卸載，同時GC會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那么在不超過MaxMetaspaceSize時，適當提高該值。
-XX:MaxMetaspaceSize，最大空間，默認是沒有限制的。
除了上面兩個指定大小的選項以外，還有兩個與 GC 相關的屬性：
-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空間容量的百分比，減少為分配空間所導致的垃圾收集 。
-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空間容量的百分比，減少為釋放空間所導致的垃圾收集。
2）慎重引用第三方包
對第三方包，一定要慎重選擇，不需要的包就去掉。這樣既有助於提高編譯打包的速度，也有助於提高遠程部署的速度。
3）關注動態生成類的框架
對於使用大量動態生成類的框架，要做好壓力測試，驗證動態生成的類是否超出內存的需求會拋出異常。
5.直接內存內存溢出
1.問題描述
在使用ByteBuffer中的allocateDirect()的時候會用到，很多javaNIO(像netty)的框架中被封裝為其他的方法，出現該問題時會拋出java.lang.OutOfMemoryError: Direct buffer memory異常。
如果你在直接或間接使用了ByteBuffer中的allocateDirect方法的時候，而不做clear的時候就會出現類似的問題。
2.示例代碼
3.解決辦法
如果經常有類似的操作，可以考慮設置參數：-XX:MaxDirectMemorySize，並及時clear內存。
6.棧內存溢出
1.問題描述
當一個線程執行一個Java方法時，JVM將創建一個新的棧幀並且把它push到棧頂。此時新的棧幀就變成了當前棧幀，方法執行時，使用棧幀來存儲參數、局部變量、中間指令以及其他數據。
當一個方法遞歸調用自己時，新的方法所產生的數據(也可以理解為新的棧幀)將會被push到棧頂，方法每次調用自己時，會拷貝一份當前方法的數據並push到棧中。因此，遞歸的每層調用都需要創建一個新的棧幀。這樣的結果是，棧中越來越多的內存將隨着遞歸調用而被消耗，如果遞歸調用自己一百萬次，那么將會產生一百萬個棧幀。這樣就會造成棧的內存溢出。
2.示例代碼
3.解決辦法
如果程序中確實有遞歸調用，出現棧溢出時，可以調高-Xss大小，就可以解決棧內存溢出的問題了。遞歸調用防止形成死循環，否則就會出現棧內存溢出。
7.創建本地線程內存溢出
1.問題描述
線程基本只占用heap以外的內存區域，也就是這個錯誤說明除了heap以外的區域，無法為線程分配一塊內存區域了，這個要么是內存本身就不夠，要么heap的空間設置得太大了，導致了剩余的內存已經不多了，而由於線程本身要占用內存，所以就不夠用了。
2.示例代碼
3.解決方法
首先檢查操作系統是否有線程數的限制，使用shell也無法創建線程，如果是這個問題就需要調整系統的最大可支持的文件數。
日常開發中盡量保證線程最大數的可控制的，不要隨意使用線程池。不能無限制的增長下去。
8.超出交換區內存溢出
1.問題描述
在Java應用程序啟動過程中，可以通過-Xmx和其他類似的啟動參數限制指定的所需的內存。而當JVM所請求的總內存大於可用物理內存的情況下，操作系統開始將內容從內存轉換為硬盤。
一般來說JVM會拋出Out of swap space錯誤，代表應用程序向JVM native heap請求分配內存失敗並且native heap也即將耗盡時，錯誤消息中包含分配失敗的大小（以字節為單位）和請求失敗的原因。
2.解決辦法
增加系統交換區的大小，我個人認為，如果使用了交換區，性能會大大降低，不建議采用這種方式，生產環境盡量避免最大內存超過系統的物理內存。其次，去掉系統交換區，只使用系統的內存，保證應用的性能。
9.數組超限內存溢出
1.問題描述
有的時候會碰到這種內存溢出的描述Requested array size exceeds VM limit，一般來說java對應用程序所能分配數組最大大小是有限制的，只不過不同的平台限制有所不同，但通常在1到21億個元素之間。當Requested array size exceeds VM limit錯誤出現時，意味着應用程序試圖分配大於Java虛擬機可以支持的數組。JVM在為數組分配內存之前，會執行特定平台的檢查：分配的數據結構是否在此平台是可尋址的。
2.示例代碼
以下就是代碼就是數組超出了最大限制。
3.解決方法
因此數組長度要在平台允許的長度范圍之內。不過這個錯誤一般少見的，主要是由於Java數組的索引是int類型。 Java中的最大正整數為2 ^ 31 - 1 = 2,147,483,647。 並且平台特定的限制可以非常接近這個數字，例如：我的環境上(64位macOS，運行Jdk1.8)可以初始化數組的長度高達2,147,483,645（Integer.MAX_VALUE-2）。若是在將數組的長度再增加1達到nteger.MAX_VALUE-1會出現的OutOfMemoryError。
10.系統殺死進程內存溢出
1.問題概述
在描述該問題之前，先熟悉一點操作系統的知識：操作系統是建立在進程的概念之上，這些進程在內核中作業，其中有一個非常特殊的進程，稱為“內存殺手（Out of memory killer）”。當內核檢測到系統內存不足時，OOM killer被激活，檢查當前誰占用內存最多然后將該進程殺掉。
一般Out of memory:Kill process or sacrifice child錯會在當可用虛擬虛擬內存(包括交換空間)消耗到讓整個操作系統面臨風險時，會被觸發。在這種情況下，OOM Killer會選擇“流氓進程”並殺死它。
2.示例代碼
3.解決方法
雖然增加交換空間的方式可以緩解Java heap space異常，還是建議最好的方案就是升級系統內存，讓java應用有足夠的內存可用，就不會出現這種問題。
內存溢出或泄露原因分析
分析堆內存溢出的原因可能如下：
使用了大量的遞歸或無限遞歸（遞歸中用到了大量的新建的對象）
使用了大量循環或死循環（循環中用到了大量的新建的對象）
類中和引用變量過多使用了Static修飾 如 public staitc Student s；在類中的屬性中使用 static修飾的最好只用基本類型或字符串。如public static int i = 0; //public static String str;
數組，List，Map中存放的是對象的引用而不是對象，因為這些引用會讓對應的對象不能被釋放，會大量存儲在內存中。
分析棧內存溢出的原因可能如下：
使用了大量的遞歸或無限遞歸
使用了大量循環或死循環（如循環中不停調用方法）
list，map，數組等長度過大等。
出現內存溢出或內存泄露的解決方案
1.修改JVM啟動參數(-Xms，-Xmx)，直接增加虛擬機內存。
2.檢查錯誤日志。
3.使用內存查看工具查看內存使用情況(如jconsole)
4.對代碼進行仔細分析，找出可能發生內存溢出的位置。
詳細排查方案如下:
檢查在數據庫中取的數據量是否超過內存
檢查是否有過大的集合或對象
檢查是死循環或遞歸是否會導致溢出
檢查是否有大量對象的創建是否會出現內存問題
檢查是否有大量的連接對象或監聽器等未關閉
......
在開發中應如何避免出現內存泄露
1.盡量少使用枚舉
2.盡量使用靜態內部類而不是內部類
3.盡量使用輕量級的數據結構
4.養成關閉連接和注銷監聽器的習慣
5.謹慎使用static關鍵字
6.謹慎使用單例模式
......