java的ImageIO处理图片

在使用Thumbnailator时出现了OOM问题，但是其使用方法只有一行代码，无法针对其内部使用的对象进行资源释放，所以使用原生的Java类库中ImageIO来处理图片。 关键有三个类：ImageIO、BufferedImage、Graphics

• ImageIO类包含两个静态方法：read()和write()，通过这两个方法即可完成对位图文件的读写，调用write()方法输出图形文件时需要指定输出的图形格式。

public static BufferedImage read(File input) throws IOException
public static boolean write(RenderedImage im,String formatName,File output)throws IOException

• Image类代表位图，但它是一个抽象类，无法直接创建Image对象，为此java为它提供了一个BufferedImage子类，这个子类是一个可以访问图像数据缓冲区的Image实现类。该类提供了一个简单的构造器：BufferedImage(int width,int height,int imageType)：创建指定大小、指定图像类型的BufferedImage对象。除此之外，还提供一个getGraphics()方法返回该对象的Graphics对象，从而允许通过该Graphics对象向BufferedImage中添加图形。
• Graphics是一个抽象的画笔对象，它可以在组件上绘制丰富多彩的几何图形和位图。它提供有一个重要方法，将一个img对象的原始图形宽度缩小为width，高度缩小为height，添加到BufferedImage对象的(x,y)处：public abstract boolean drawImage(Image img, int x, int y,int width,int height, ImageObserver observer)

关键的像素位乘积可能导致内存暴涨以至出现OOM

BufferedImage.java:324，DirectColorModel.java:1032，Raster.java:467，DataBufferInt.java:75

至此可以得知，提示OOM的原因为图片的宽度和高度的像素乘积过大导致在初始化int的数组的时候出现 java.lang.OutOfMemoryError: Java heap space。

BufferedImage的一些坑

BufferedImage 的一些坑：

• 项目中，

BufferedImage

• 的读取加载流程是：下载图片 -> 通过

ImageIO.read()

• 转成

BufferedImage

• 。很有可能的是，下载的图片过大，那么转成

BufferedImage

• 的对象也会很大。
• 此外

BufferedImage

• 存储的内容是不经过压缩的，你本地磁盘上读取了一个图片文件，转成

BufferedImage

• 对象后，大小可能是文件大小的数倍。这是因为

BufferedImage

• 的对象大小是要按照位图那一套算法计算的，即

像素数 * 单个像素存储大小

• 。一般项目中都是用彩图，即24位。

• 一个例子：一张1200 * 900的彩图A和黑白图B，大小分别为800KB和100KB，均为JPG格式，但是读到内存里后，大小变为了3MB多，这是因为它们都用彩图存储（

ImageIO.read()

• 就是这么处理的），且

size = 1200 * 900 * 24 / 8 = 3240000 bytes

• 。

所以当要缓存图片或者大对象（包含大量字节串）的时候，可以考虑：

• 对对象进行压缩（显然

BufferedImage

• 压缩比较困难，可以用第三方库？）
• 另外我认为，对于图像的缓存（或者是大的

byte[]

• 对象），应该利用磁盘缓存或者用类似Redis那样的缓存，而不是保存在本机内存里

结论

• 1、java对于图片的处理技术在处理小图片时，完全够用，但是在处理大于1MB以上的图片时，就不再推荐本身服务器去处理图片。
• 2、有条件的还是将图片的处理交给第三方来，调用封装好的API等来处理图片的各种要求。

参考链接

https://keys961.github.io/2018/05/28/JVM%E5%A0%86%E5%86%85%E5%AD%98%E5%88%86%E6%9E%90/

本篇文章如有帮助到您，请给「翎野君」点个赞，感谢您的支持。

作者：翎野君