可以看出，/proc/sys是一個虛擬文件系統，可以通過對它的讀寫操作做爲與kernel實體間進行通信的一種手段。也就是說可以通過修改/proc中的文件，來對當前kernel的行爲做出調整。那麼我們可以通過調整/proc/sys/vm/drop_caches來釋放內存。其默認數值爲0. 向/proc/sys/vm/drop_caches中寫入內容，會清理緩存。建議先執行sync（sync 命令將所有未寫的系統緩衝區寫到磁盤中，包含已修改的 i-node、已延遲的塊 I/O 和讀寫映射文件）。執行echo 1、2、3 至 /proc/sys/vm/drop_caches, 達到不同的清理目的。
echo N > /proc/sys/vm/drop_caches ，我們可以使用如下的代碼替換：
int DropCaches(int drop)
{
int ret = 0;
#ifdef WIN32
#else
int fd = 0;
fd = open("/proc/sys/vm/drop_caches", O_RDWR);
if(fd < 0)
{
return -1;
}
char dropData[32] = { 0 };
int dropSize = snprintf(dropData,sizeof(dropData),"%d",drop);
ret = write(fd,dropData,dropSize);
close(fd);
#endif
return ret;
}
別人給出的建議：
如果因爲是應用有像內存泄露、溢出的問題，從swap的使用情況是可以比較快速可以判斷的，但free上面反而比較難查看。相反，如果在這個時候，我們告訴用戶，修改系統的一個值，“可以”釋放內存，free就大了。用戶會怎麼想？不會覺得操作系統“有問題”嗎？所以說，既然核心是可以快速清空buffer或cache，也不難做到（這從上面的操作中可以明顯看到），但核心並沒有這樣做（默認值是0），我們就不應該隨便去改變它。
一般情況下，應用在系統上穩定運行了，free值也會保持在一個穩定值的，雖然看上去可能比較小。當發生內存不足、應用獲取不到可用內存、OOM錯誤等問題時，還是更應該去分析應用方面的原因，如用戶量太大導致內存不足、發生應用內存溢出等情況，否則，清空buffer，強制騰出free的大小，可能只是把問題給暫時屏蔽了。
排除內存不足的情況外，除非是在軟件開發階段，需要臨時清掉buffer，以判斷應用的內存使用情況；或應用已經不再提供支持，即使應用對內存的時候確實有問題，而且無法避免的情況下，才考慮定時清空buffer。（可惜，這樣的應用通常都是運行在老的操作系統版本上，上面的操作也解決不了）