<b>1.2.4 新的問題</b>
經過上一輪的優化，在記憶體螢幕裡新版本的heap記憶體表現已經比較好了，新功能隻消耗了幾萬位元組到幾十萬位元組記憶體。但是要注意的是，heap記憶體并不是應用的全部，我們在設定或其他管理工具裡看到的應用記憶體大小是應用整個程序的記憶體使用量。也有可能出現heap部分完全沒有增長而其他部分增長的情況。
要觀察程序的記憶體使用情況，就需要用到其他的觀測工具，android裡最常用于觀察程序記憶體的方法就是dumpsys meminfo <package name|pid>指令。
對我們的新版應用執行該指令，能夠得到以下的輸出結果：
** meminfo in
pid 17481 [com.example] **
shared private
heap heap heap
pss dirty
dirty size alloc
free
------ ------
------ ------ ------
------
native 28
8 28 5744
3739 1117
dalvik heap
10112 10224 9624
14076 10386 3690
dalvik other 3212
3076 0 0
stack 270
270 0 0
ashmem 2
0 0 0
other dev 7
0 4 0
.so mmap 1867
1330 160 0
.jar mmap 4
.apk mmap 2944
0 2690 0
.dex mmap 4110
64 3420
other mmap 16
4 4 0
unknown 2351
2331 0 0
total
24895 12404 6212
在以上輸出結果中，左邊pss列的資料辨別程序各部分對真實實體記憶體的消耗，左下角的total值就是我們在各種管理工具裡看到的應用記憶體消耗。
而android studio等工具裡顯示的記憶體值，在這裡是dalvik heap alloc部分。根據以上的資料，我們可以看到dalvik heap和heap alloc不是相等的，而且除了dalvik heap之外，還有其他很多部分也會消耗記憶體。
這時候我們再對比一下舊版，看看是否也如此：
pid 14233 [com.example] **
pss
dirty dirty size
alloc free
8 28 5664
3767 1040
dalvik heap
8026 10372 7508
11784 10113 1671
dalvik other
3159 3076 0
stack 260
260 0 0
.so mmap 1887
1344 160 0
.apk mmap 2941
0 2680 0
.dex mmap 4013
64 3360 0
unknown 2256
2244 0 0
total
22599 17372 13716
這時候就會發現問題了，heap alloc沒增加多少，但dalvik heap pss增加了許多。而其他部分基本保持不變或有少量增長。可見問題還是出現在dalvik heap部分，但隻靠檢查配置設定的對象是看不出來問題的。
java代碼的記憶體配置設定和釋放都是由虛拟機管理的，那麼這個問題會是虛拟機的問題嗎？我們接下來繼續通過虛拟機部分機制來探索這些記憶體增長的原因。
![Java小案例——随機數猜測随機數猜測[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)