我想這樣不行吧， 至少要一張圖片一張圖片的壓縮。如果你讀固定長度，一張圖片沒讀完就壓縮肯定會有問題
B. graphicsmagick在java中怎麼使用
伺服器端圖片上傳邏輯改版，將文件自己壓縮成3份然後上傳至某雲進行存儲。
選擇GraphicsMagick+IM4Java，放棄並發能力弱的ImageMagick+Jmagick。
網上可供學習GraphicsMagick與IM4Java的資料是在太少，翻來覆去就那麼幾篇，碰到異常只能一遍又一遍的研讀官方文檔！這也是我寫這篇文章的原因之一。
im4java參考資料：
1）請詳見Developer's Guide: http://im4java.sourceforge.net/docs/dev-guide.html
2）github上im4java的源碼：https://github.com/Widen/im4java
GraphicsMagick參考資料：
1）http://www.graphicsmagick.org
先在本地安裝使用測試，覺得性能還OK的話，再放到測試伺服器上部署測試實際性能。本地環境是win，win下的GM（GraphicsMagick）就很好安裝了，與普通軟體安裝無異。
二）使用IM4Java：
瞧Developer's Guide中的「Before you begin: Setting up the Environment」內容，大意是使用之前先設置工具的工具（當然壓縮圖片的工具，名字叫gm）的搜索路徑，並說明了這幾種設置方式的差別。
比如win下的安裝路徑，假如我安裝的路徑是D:\GraphicsMagick-1.3.19-Q16，則代碼為：
String myPath="D:\\GraphicsMagick-1.3.19-Q16";
ProcessStarter.setGlobalSearchPath(myPath);
註：我們不能在linux伺服器中這么寫代碼，linux直接就設置環境變數：export PATH=$PATH:/abc...,其中/abc是你的GM工具所在路徑，比如我的是/home/db/roderickyu/soft/bin
簡單用法就直接看文檔吧，我這里寫幾個文檔里不太容易讀出來的內容：
壓縮時可以直接添加本地的圖片，比如：
IMOperation op = new IMOperation();
op.addImage("D:\\test.jpg"); // 輸入要壓縮的文件路徑
op.resize(640); // 多番嘗試後才知道這是限定width，height等比縮放
op.addImage("D:\\newTest.jpg"); // 壓縮後的文件的輸出路徑，當然可以沒有擴展名！
還有一種是對輸入流進行壓縮，比如官方文檔中：
IMOperation op = new IMOperation();
op.addImage("-"); // read from stdin
op.addImage("tif:-"); // write to stdout in tif-format
代碼中tif是指按照tif格式進行壓縮，但是變化不明顯（而且壓縮後的大小與size大小不成正比），很容易給初學者造成是不是代碼不好使的挫敗感！將tif換成jpg壓縮的大小變化就明顯了。這是一個坑！
回到這個需求來，我們只有一個輸入流，怎麼把這個輸入流壓縮成3份大小不等的文件呢？
將輸入流轉化成byte數組，就不存在流被第一個文件讀完第二三的文件沒有流可以讀時報異常。。。empty input file...
代碼為：
InputStream fileStream = ......
int total = fileStream.available();
byte[] bs = new byte[total];
fileStream.read(bs);
按照GM的官方文檔安裝GM時失敗，後才得解：安裝路徑不是當前linux用戶的可讀寫許可權內的路徑，換成當前身份可讀寫的路徑唄或者換登入身份唄~
最後測試，發現性能相當優異！
C. GraphicsMagick安裝，如何用C語言測試安裝成功與否
在C中可以通過程序來調用其他的程序:
例如:ShellExecute();(我這個只是舉個例子)
具體的做法你可以自己去查看C的庫函數以及系統API的用法
D. 我做了一個圖片上傳，後台總提示Tomcat內存溢出，怎麼解決，調整Tomcat的內存大小包括注冊表都試過沒用。
圖片壓縮下再傳看看，是不是資料庫限制圖片格式或大小？
Tomcat內存溢出的原因
在生產環境中tomcat內存設置不好很容易出現內存溢出。造成內存溢出是不一樣的，當然處理方式也不一樣。
這里根據平時遇到的情況和相關資料進行一個總結。常見的一般會有下面三種情況：
1.OutOfMemoryError： Java heap space
2.OutOfMemoryError： PermGen space
3.OutOfMemoryError： unable to create new native thread.
Tomcat內存溢出解決方案
對於前兩種情況，在應用本身沒有內存泄露的情況下可以用設置tomcat jvm參數來解決。（-Xms -Xmx -XX：PermSize -XX：MaxPermSize）
最後一種可能需要調整操作系統和tomcat jvm參數同時調整才能達到目的。
第一種：是堆溢出。
原因分析：
JVM堆的設置是指java程序運行過程中JVM可以調配使用的內存空間的設置.JVM在啟動的時候會自動設置Heap size的值，其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可進行設置。Heap size 的大小是Young Generation 和Tenured Generaion 之和。
在JVM中如果98％的時間是用於GC且可用的Heap size 不足2％的時候將拋出此異常信息。
Heap Size 最大不要超過可用物理內存的80％，一般的要將-Xms和-Xmx選項設置為相同，而-Xmn為1/4的-Xmx值。
沒有內存泄露的情況下，調整-Xms -Xmx參數可以解決。
-Xms：初始堆大小
-Xmx：最大堆大小
但堆的大小受下面三方面影響：
1.相關操作系統的數據模型（32-bt還是64-bit）限制；（32位系統下，一般限制在1.5G~2G；我在2003 server 系統下（物理內存：4G和6G，jdk：1.6）測試 1612M，64位操作系統對內存無限制。）
2.系統的可用虛擬內存限制；
3.系統的可用物理內存限制。
堆的大小可以使用 java -Xmx***M version 命令來測試。支持的話會出現jdk的版本號，不支持會報錯。
-Xms -Xmx一般配置成一樣比較好比如set JAVA_OPTS= -Xms1024m -Xmx1024m
其初始空間(即-Xms)是物理內存的1/64，最大空間(-Xmx)是物理內存的1/4。可以利用JVM提供的-Xmn -Xms -Xmx等選項可
進行設置
實例，以下給出1G內存環境下java jvm 的參數設置參考：
JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "
JAVA_OPTS="-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m -XX:
NewSize=192m -XX:MaxNewSize=384m"
CATALINA_OPTS="-server -Xms768m -Xmx768m -XX:PermSize=128m -XX:MaxPermSize=256m
-XX:NewSize=192m -XX:MaxNewSize=384m"
伺服器為1G內存：JAVA_OPTS="-server -Xms800m -Xmx800m -XX:PermSize=64M -XX:MaxNewSize=256m -XX:MaxPermSize=128m -Djava.awt.headless=true "
伺服器為64位、2G內存: JAVA_OPTS='-server -Xms1024m -Xmx1536m -XX:PermSize=128M -XX:MaxNewSize=256m -XX:MaxPermSize=256m'
在網上搜索 Tomcat內存溢出的三種情況及解決辦法分析