你可能想，為什麼要談內存，我們可愛的Java不是有gc機制嗎?可惜我們現在不是在pc上，而是只有64k內存的手機。如果不多加小心謹慎的話，我們的gc很可能每十秒鐘運行一次呢。你會不會毫不猶豫地寫下這樣的代碼:
Java手機網[www.cnjm.Net]
代碼：
1.
g.drawString(“score=”+score，50，50，Graphics.TOP|Graphics。LEFT);
Java手機網[www.cnjm.Net] 或是
2.
for (Enumeration e = v.elements() ; e.hasMoreElements() ;) {
System.out.println(e.nextElement());
}
有什麼問題?其實它做了下面的事:
代碼：
String scoreStr=“score=”+score;
g.drawString(scoreStr，50，50，Graphics.TOP|Graphics.LEFT);
明白了嗎?在你的J2ME游戲裡，這行程序很可能在paint()裡面出現並且每0.1秒運行一次吧。伴隨著時間的推移，成堆的String被創建出來，要不了多久，我們可愛的gc媽媽就要出來喽。想到了就簡單了，根據我們midlet的實際情況，讓我們靈活地建立解決de方法。
差不多也發生了同樣的事情，注意到interface Enumeration只有兩個method:
boolean hasMoreElement();
Object nextElement();
發現了什麼?Enumeration不像STL的iterator，沒法讓一個原有的Enumeration從頭開始，每遍歷一次我們的Vector或Hashtable，我們就得問我們的容器要一個新的Enumeration。
Java手機網[www.cnjm.Net]常見的情況是:
Java手機網[www.cnjm.Net]
碰撞檢測。我們不得不在每一個frame裡對容器做遍歷，其結果就是生出以集裝箱為單位的大把Enumeration，使用Enumeration很酷，不過為了內存，我們還是老土一點:
代碼：
for (int loop, n = vector.size(); loop < n; loop++) {
System.out.println(vector.elementAt(loop));
}
最後，只要善用wtk的Monitor，就能及時地發現我們MIDlet中的內存殺手，將lag消餌於無形之中。
