我們有一個服務器（Java EE）應用程序，它會根據用戶請求做一些圖像處理工作。諸如將圖像格式（例如TIFF轉換爲JPEG），將圖像顏色（例如，RGB到灰度轉換爲BW），重新採樣（調整大小）圖像。印刷行業的一些客戶使用非常大的圖像，如2000 dpi，6 * 8英寸，4種顏色組件，這將需要6 * 2000 * 8 * 2000 * 4 = 768MB內存。服務器無法在內存中保存大圖像，因此我們決定按條帶進行條帶化處理。問題是仍然不起作用，因爲可能同時有許多客戶。你對如何實現內存有限的圖像處理有任何想法嗎？或者，你知道是否有一些紙張/文章可以爲我們提供解決方案。服務器內存限制圖像處理
感謝，
那麼你應該知道的第一件事是，你的內存可以分配的金額並不取決於你有多少RAM。操作系統管理虛擬內存，任何分配都在虛擬內存中完成。然後由操作系統將塊分頁到RAM /磁盤。你無法控制這一點。你可能會認爲你在RAM中分配了5MB的內存，但是這取決於操作系統將其保存在內存中，或者在你需要時將它從磁盤上獲取到你的程序中。在Windows 32位中，用戶空間中有2 GB用於處理（其餘部分由內核空間使用）。在64位的操作系統中，數量要大得多。
但是，僅僅因爲您有2 GB的用戶空間可以分配（在32位操作系統中或64位以上）並不意味着您可以始終分配一個很大的塊，因爲內存分配需要連續的內存塊。所以內存碎片可能成爲一個問題。
第三件事是JVM限制你可以分配的內存量。因此，您需要通過-Xms -Xmx參數來增加這些參數，以限制堆大小。
除了這些評論，我沒有真正爲你解決的。
是的我完全理解VM機制。我的問題是我們想要一個能夠在有限內存大小（如64MB）下處理圖像的解決方案。簡單地放大記憶不是我們的首選。實際上我們所做的只是使用64位機器，併爲-Xmx設置了非常大的值。但這對32位機器不起作用。 – xeranic 2010-04-13 16:59:44
是的。我不認爲有任何簡單的解決方案。就像你說的，你可以把它分解成大塊的處理，但時間對其他客戶來說變得重要。您可以考慮在OpenCL（或CUDA）中實現算法，並使用GPU陣列從並行處理中獲得更快的速度。諸如圖像編碼之類的東西通常在獨立塊中完成，所以這些算法很好地進行縮放 – Budric 2010-04-13 17:06:01
您可以使用「平鋪」圖像處理技術。例如，IPP支持平鋪圖像處理。
您是否知道英特爾IPP在平鋪圖像處理方面的最佳做法教程？例如，什麼是最優化的圖塊形狀（內存連續性的行數，還是在非連續內存中剪切圖像但緩存中的圖像更小的矩形）？ – Royi 2016-10-09 08:26:52
我建議考慮將圖像處理部分移動到單獨的 JVM中，您可以使用RMI或類似語言從主應用程序與之通信。
這使您可以獨立於主JVM調整處理JVM，甚至可以在多臺機器上創建分佈式系統（如果需要的話）。這也可以讓你管理轉換，以便只有少數人同時發生更大的單個圖像。
是否有任何限制會阻止你這樣做？
作爲最後的手段，我建議將實際的圖像轉換移動到本地程序，如Linux上的ImageMagick，然後由您的程序調用，進行轉換，並讓您的JVM將結果傳遞給用戶。這可以說是更快的CPU明智和需要更少的內存。
購買更多硬件 – Pyrolistical 2010-04-13 17:05:40