ImageIO.read(URL)需要永远加载图像
我正在用JavaEE技术实现REST-API，这些技术将被移动应用程序访问，并响应他们的请求用一些JSON数据进行应答。到目前为止，一切都很好，直到我们注意到一个查询花费了非常长的时间。起初，我认为这是一个运行时间太长的“复杂”数据库查询，但经过一些调试后，它指出，通过ImageIO.read(URL)方法访问检索到的数据的缩略图是请求采取因此 long 的原因。
通过数据库查询，我正在检索指向我想要检索的(缩略图)图像数据的URL。在创建对象的JSON-数据以将其发送回客户端之前，我将将Image编码为Base64 64-字符串。
我的代码看起来如下(我知道它目前还不太好，但这就是我现在让它工作的方式，我知道我可以使用尝试-资源块，并且可能应该将日志转换为日志级别的调试，我打算这样做)：
public class Base64Utility
{
public static String encodeBase64FromUrl(final URL pImageUrl, final ThumbnailPictureDbo pThumbnailPicture)
{
BufferedImage img = null;
String base64EncodedImageString = null;
final ByteArrayOutputStream bos = new ByteArrayOutputStream();
byte[] imageBytes = null;
try
{
logger.info("Starting to convert the image!");
final Long start = System.currentTimeMillis();
// The Sucker!
img = ImageIO.read(pImageUrl);
final Long imageLoadTime = System.currentTimeMillis() - start;
logger.info("Loaded Image from url {} in: {}", pImageUrl, imageLoadTime);
final Long start2 = System.currentTimeMillis();
ImageIO.write(img, "png", bos);
imageBytes = bos.toByteArray();
final Long imageWriteTime = System.currentTimeMillis() - start2;
logger.info("Wrote Image in: {}", imageWriteTime);
bos.close();
final Long start3 = System.currentTimeMillis();
// What to return when img == null?!
base64EncodedImageString = imageBytes != null ? Base64.getEncoder()
.encodeToString(imageBytes) : "";
final Long imageEncodeTime= System.currentTimeMillis() - start3;
logger.info("Encoded Image in: {}", imageEncodeTime);
pThumbnailPicture.setBase64EncodedImage(base64EncodedImageString);
logger.info("Finished converting the image!");
logger.info("Took total time: " + (System.currentTimeMillis() - start));
return base64EncodedImageString;
}
catch (final IOException e)
{
e.printStackTrace();
}
return base64EncodedImageString;
}映像托管在上，与数据库所在的相同，代码运行在上。因此，URL-param包含它的主机名，但也可以通过"localhost“或作为文件访问它(但是它与数据库中的主机名一起存储。为了方便起见，我没有转换它，我还找到了非常方便的ImageIO.read(URL)方法。因此，网络也不应该成为瓶颈。
非常奇怪的行为是，ImageIO通过第一个调用上的url访问图像需要10-60秒。，(同一个客户端请求中的多个结果-数据)，仅需100毫秒。
对于一个新的请求，它的行为是相同的(第一个调用占用异常长，而接下来的调用非常短)。这是一些日志的输出(在客户机的一个请求期间！)：
Starting to convert the image!
Loaded Image from url <URL>/Logo-KF-transparent-1500-1024x992.png in: 21810
Wrote Image in: 973
Encoded Image in: 3
Finished converting the image!
Took total time: 22787
Starting to convert the image!
Loaded Image from url <URL>/IMG_1026_905.jpg in: 157
Wrote Image in: 440
Encoded Image in: 7
Finished converting the image!
Took total time: 605
Starting to convert the image!
Loaded Image from url <URL>/WorkshopS2_KaffeeFabrik_1200x800-500x300.jpg in: 23
Wrote Image in: 101
Encoded Image in: 2
Finished converting the image!
Took total time: 127
Starting to convert the image!
Loaded Image from url <URL>/kaffeezumabnehmen.jpg in: 226
Wrote Image in: 98
Encoded Image in: 4
Finished converting the image!
Took total time: 329
Starting to convert the image!
Loaded Image from url <URL>/kaffee_apa.jpg in: 12
Wrote Image in: 60
Encoded Image in: 2
Finished converting the image!
Took total time: 75因此，行为不依赖于--映像--也不依赖于--映像的格式，它总是第一次访问/加载，花费了这么长时间！有谁有主意或解决办法吗？我对另一种读取/加载图像的方法也很满意，这只是我的第一次尝试，也是我自己一些研究的第一个结果。也许有完全不同和更好的方法来做到这一点。
我以这种方式调用RequestScoped中的实用程序：
@RequestScoped
public class LocationPersistenceServiceImpl implements LocationPersistenceService
{
// Some other attributes and methods...
@Override
public List<LocationData> findLocations(final QueryParams[] pQueryParams)
{
final QueryBuilder<LocationDbo> qb = new QueryBuilder<>(pQueryParams, emf, LocationDbo.class);
final List<LocationDbo> locationDboQueryResults = qb.getResultList();
for (LocationDbo retrievedLocDbo : locationDboQueryResults)
{
retrievedLocDbo = enhanceRetrievedLocationDboMetaInformation(retrievedLocDbo);
}
return dboToData.convert(locationDboQueryResults);
}
private LocationDbo enhanceRetrievedLocationDboMetaInformation(LocationDbo pRetrievedLocDbo)
{
final List<PostMetaInformationDbo> postMetaInfos = pPs.retrievePostMetaInfomationsById(pRetrievedLocDbo.getPostId());
pRetrievedLocDbo = addRetrievedLocationMetaInfosFromLocationPost(pRetrievedLocDbo, postMetaInfos);
return pRetrievedLocDbo;
}
private LocationDbo addRetrievedLocationMetaInfosFromLocationPost(final LocationDbo pLocDbo, final List<PostMetaInformationDbo> pPostMeta)
{
for (final PostMetaInformationDbo p : pPostMeta)
{
// Some code...
}
if ((pLocDbo.getThumbnailPicture() != null) && (!StringUtils.isBlank(pLocDbo.getThumbnailPicture()
.getGuid())))
{
Base64Utility.encodeBase64FromUrl(pLocDbo.getThumbnailPicture()
.getGuid(), pLocDbo.getThumbnailPicture());
}
return pLocDbo;
}
}我的另一个想法是将Base64Utility类注释为无状态bean，并将其注入服务类。也许这可以改进一些缓存/连接过程，或者支持一些并行执行/线程等(还没有尝试过)。
也许有人有类似的问题，或者在与ImageIO合作时看到了明显的错误，并且可以分享他的知识。
谢谢，并致以最良好的问候！
P.S.：整个代码在Wildlfy (8.2.Final和Java8)应用服务器中运行。因此，在使用ImageIO时手动启动一些线程(我的研究中的一些帖子是如何建议的)不应该是个好主意。
回答 1
Stack Overflow用户
发布于 2016-10-10 16:31:11
正如它所指出的，它不是ImageIO的直接问题，而且它与一个缓慢/配置错误的Apache服务器有关。只需重新启动Apache服务器(它为映像提供服务)就可以解决我的问题。
https://stackoverflow.com/questions/39932629
复制相似问题
腾讯云开发者
