在多線程環(huán)境中詢問運行時的可用內(nèi)存量并不可靠,因為在測量之后內(nèi)存可能會被另一個線程用完.此外,您正在使用maxMemory – usedMemory,這不是可用內(nèi)存量,而是VM認(rèn)為它最多可用的內(nèi)容 – 可能是主機系統(tǒng)無法滿足更多內(nèi)存的請求,而VM仍然認(rèn)為它可以擴大堆.

它也完全有可能你的VM有108 MB免費,但一個塊沒有20MB可用.您嘗試創(chuàng)建的BufferedImage類型最終由int []數(shù)組支持,該數(shù)組必須作為一個重要的內(nèi)存塊進行分配.這意味著如果堆上沒有可用的20MB塊,那么無論有多少總可用內(nèi)存,您都會得到一個OutOfMemoryError.使用垃圾收集器使情況更加復(fù)雜 – 每個GC都有不同的內(nèi)存分配策略;可以為磁盤本地內(nèi)存分配留出相當(dāng)大一部分的堆.

在沒有任何信息的情況下,堆總共有多大,你正在使用哪個GC(以及哪個虛擬機),有太多的變量指責(zé)罪魁禍?zhǔn)?

編輯：找出使用的GC(Java 7 (JDK 7) garbage collection and documentation on G1)并了解其具體的優(yōu)缺點 – 尤其是它在堆壓縮方面提供的功能以及默認(rèn)情況下其生成的大小.這將是要玩的參數(shù).使用GC消息運行應(yīng)用程序也可以提供有關(guān)最新情況的見解.

考慮到你的堆大小只有900MB,100MB空閑意味著你已經(jīng)非常接近極限 – 我的第一個解決辦法是簡單地為VM分配一個更大的堆,比方說2GB.如果你需要節(jié)省內(nèi)存,你唯一的選擇是調(diào)整GC參數(shù)(可能選擇另一個GC) – 說實話我沒有經(jīng)驗.不過,有很多關(guān)于GC調(diào)整主題的文章.

總結(jié)

以上是生活随笔為你收集整理的java image 内存_Java BufferedImage内存消耗的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。