我編寫了一個小程序，並在Solaris/Linux平臺下編譯它以測量將此代碼應用於我的應用程序的性能。在Solaris/Linux中釋放分配的內存
程序是這樣編寫的，最初使用的是一個sbrk(0)系統調用，我已經佔用了堆區的基地址。之後，我使用系統調用malloc分配了1.5 GB的內存，然後我使用memcpy系統調用將1.5 GB的內容複製到分配的內存區域。然後，我釋放了分配的內存。
釋放後，我再次使用sbrk(0)系統調用來查看堆大小。
這是我有點困惑。在Solaris中，儘管我釋放了分配的內存（接近1.5 GB），但該進程的堆大小很大。但是我在Linux中運行相同的應用程序，在釋放之後，我發現該進程的堆大小等於分配1.5 GB之前的堆內存大小。
我知道Solaris沒有立即釋放內存，但我不知道如何調整Solaris內核以在系統調用free()之後立即釋放內存。
爲什麼我在Linux下沒有同樣的問題？
我得到了我問過的問題的答案。
應用內存分配：
C和C++開發者必須手動管理存儲器分配和釋放存儲器。默認的內存分配器位於libc庫中。
Libc 請注意，執行free（）後，釋放的空間可供應用程序進一步分配，而不返回給系統。只有當應用程序終止時，內存纔會返回到系統。這就是爲什麼應用程序的進程大小通常不會減少。但是對於長期運行的應用程序，應用程序進程大小通常保持穩定狀態，因爲釋放的內存可以重用。如果不是這種情況，那麼很可能應用程序正在泄漏內存，也就是說，分配的內存被使用，但是在不再使用時永遠不會釋放，並且指向分配的內存的指針不會被應用程序追蹤 - 基本上會丟失。
當併發malloc或free操作頻繁發生時，libc中的缺省內存分配器對於多線程應用程序並不好，特別是對於多線程C++應用程序。這是因爲創建和銷燬C++對象是C++應用程序開發風格的一部分。當使用默認的libc分配器時，堆由單個堆鎖保護，由於在malloc或free操作期間發生嚴重鎖定爭用，導致默認分配器無法針對多線程應用程序進行擴展。使用Solaris工具檢測此問題很容易，如下所示。
首先，使用prstat -mL -p來查看應用程序是否在鎖上花費很多時間;看看LCK專欄。例如：
-bash-3.2# prstat -mL -p 14052
PID USERNAME USR SYS TRP TFL DFL LCK SLP LAT VCX ICX SCL SIG PROCESS/LWPID
14052 root 0.6 0.7 0.0 0.0 0.0 35 0.0 64 245 13 841 0 test_vector_/721
14052 root 1.0 0.0 0.0 0.0 0.0 35 0.0 64 287 5 731 0 test_vector_/941
14052 root 1.0 0.0 0.0 0.0 0.0 35 0.0 64 298 3 680 0 test_vector_/181
14052 root 1.0 0.1 0.0 0.0 0.0 35 0.0 64 298 3 1K 0 test_vector_/549
....
它顯示應用程序花費大約35％的時間在等待鎖。
然後，使用plockstat（1M）工具查找應用程序正在等待的鎖定。例如，使用進程ID 14052跟蹤應用程序5秒鐘，然後使用C++ filt實用程序過濾輸出以對C++符號名稱進行取消處理。 （C++ filt實用程序隨Sun Studio軟件一起提供。）如果應用程序不是C++應用程序，則不需要通過C++ filt進行過濾。
-bash-3.2# plockstat -e 5 -p 14052 | c++filt
Mutex block
Count nsec Lock Caller
-------------------------------------------------------------------------------
9678 166540561 libc.so.1‘libc_malloc_lock libCrun.so.1‘void operator
delete(void*)+0x26
5530 197179848 libc.so.1‘libc_malloc_lock libCrun.so.1‘void*operator
new(unsigned)+0x38
......
從前面，你可以看到堆鎖libc_malloc_lock在很大程度上爭，是規模問題的可能原因。 libc分配器的這種擴展問題的解決方案是使用改進的內存分配器，如libumem庫。
還可以訪問：http://developers.sun.com/solaris/articles/solaris_memory.html
感謝所有誰試圖回答我的問題， Santhosh。