当前位置: 首页 > 面试题库 >

JAI关闭文件句柄为时过早吗?

阎功
2023-03-14
问题内容

我正在使用JAI读取Java中的Tiff文件。使用此代码:

RenderedOp renderer = JAI.create("fileload", tifFilename);
return renderer.getAsBufferedImage();

在使用Java 7的一个盒子上工作正常,但在使用Java 8的其他盒子上工作正常,请执行以下操作:

Caused by: com.sun.media.jai.codecimpl.util.ImagingException
    at com.sun.media.jai.codecimpl.ImagingListenerProxy.errorOccurred(ImagingListenerProxy.java:63)
    at com.sun.media.jai.codecimpl.TIFFImage.getTile(TIFFImage.java:1087)
    at javax.media.jai.RenderedImageAdapter.getTile(RenderedImageAdapter.java:148)
    at javax.media.jai.NullOpImage.computeTile(NullOpImage.java:162)
    at com.sun.media.jai.util.SunTileScheduler.scheduleTile(SunTileScheduler.java:904)
    at javax.media.jai.OpImage.getTile(OpImage.java:1129)
    at javax.media.jai.PlanarImage.copyData(PlanarImage.java:2343)
    at javax.media.jai.RenderedImageAdapter.copyData(RenderedImageAdapter.java:163)
    at javax.media.jai.RenderedOp.copyData(RenderedOp.java:2299)
    at javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2525)
    at javax.media.jai.PlanarImage.getAsBufferedImage(PlanarImage.java:2546)
    at  ...
Caused by: com.sun.media.jai.codecimpl.util.ImagingException: IOException occured while reading TIFF image data.
    ... 17 more
Caused by: java.io.IOException: Stream Closed
    at java.io.RandomAccessFile.seek0(Native Method)
    at java.io.RandomAccessFile.seek(RandomAccessFile.java:557)
    at com.sun.media.jai.codec.FileSeekableStream.read(FileSeekableStream.java:168)
    at com.sun.media.jai.codec.SeekableStream.readFully(SeekableStream.java:318)
    at com.sun.media.jai.codecimpl.TIFFImage.getTile(TIFFImage.java:1081)
    ... 16 more

问题答案:

我的理论是,垃圾回收正在启动并完成一些本不该垃圾回收的工作。很奇怪。替换为:

try (SeekableStream seekableStream = new FileSeekableStream(filename)){
  TIFFDecodeParam param = null;
  ImageDecoder dec = ImageCodec.createImageDecoder("tiff", seekableStream, param);
  // convert to buffered image if desired
  return new RenderedImageAdapter(dec.decodeAsRenderedImage()).getAsBufferedImage(); // convert to buffered image
}

问题似乎消失了。我的猜测是因为FileSeekableStream s不会过早收集,因为它的句柄仍在局部变量范围内。可能还有其他JAI方法也可以做到这一点,只要确保在输入流上保留自己的句柄即可[?]

不确定是否也适用于其他图像格式



 类似资料:
  • 函数名称:关闭文件句柄 函数功能:关闭文件句柄 函数方法 io.close() 函数用例 file,msg = io.open("/mnt/sdcard/kazhu.txt") if file then dialog("打开成功",5000) file:close() else dialog("打开失败,失败原因:"..msg,5000) end

  • 问题内容: 我想使用posix_spawn(…)(或非常相似的东西)生成一个进程集合。此函数接受posix_spawn_file_actions_t类型的参数,该参数允许我指定应如何对待打开的文件句柄。从文档中可以确定,所有文件都是从调用进程继承的,并根据posix_spawn_file_actions_t结构中的信息进行了修改。 我希望所有文件都不会被生成的进程打开(stdin,stdout和s

  • 请参见下面编辑部分的更新问题 我试图使用GZIPInputStream动态地从Amazon S3解压大型(约300M)GZIPed文件,但它只输出文件的一部分;但是,如果在解压缩之前下载到文件系统,那么GZIPInputStream将解压缩整个文件。 如何让GZIPInputStream解压整个HTTPInputStream,而不仅仅是它的第一部分? 请参见下面编辑部分中的更新 我怀疑是HTTP问

  • 问题内容: 我正在开发一个巨大的旧版Java应用程序,其中包含许多手写内容,如今您可以让一个框架来处理。 我现在面临的问题是,我们的Solaris Server上的文件句柄用尽了。我想知道跟踪打开文件句柄的最佳方法是什么?在哪里查看,什么会导致打开的文件句柄用尽? 我不能在Solaris下调试应用程序,只能在Windows开发环境上调试。分析Windows下的打开文件句柄是否甚至合理? 问题答案:

  • 我的nginx配置: 这是nginx或uwsgi的问题,还是两者都有?

  • 对于来自Android应用程序的所有网络流量,我们都使用retrofit/okhttp3。到目前为止,一切似乎都进行得相当顺利。 然而,我们现在偶尔会出现应用程序/进程用完文件句柄的情况。 null null 如何防止OkHttp创建太多的文件句柄?