Question

我正在使用JavaEE-Techniques实现一个REST-API，它将由移动应用程序访问并回答一些JSON-Data以响应他们的请求。到目前为止，一切正常，直到我们注意到一个不寻常的查询。起初我认为这是一个运行时间很长的“复杂”数据库查询，但经过一些调试后，它指出通过 ImageIO.read（URL）方法访问检索到的数据的缩略图是请求采取以及长的原因。

通过数据库查询，我正在检索指向我想要检索的（缩略图）图像数据的URL。在我创建对象的JSON-Data以将其发送回客户端之前，我将把Image编码为Base64-String。

我的代码如下所示（我知道它现在不是很好，但这就是我现在使用它的方式，我知道我可以使用try-resource块并且应该将日志记录转换为日志-level debug，我要去）：

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需要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-CDI bean调用该实用程序：

@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和Java 8）Application Server上运行。因此，在使用ImageIO时手动启动一些线程（我的研究中的一些帖子如何建议）应该不是一个好主意。

Answer 1

正如它所指出的那样，它不是ImageIO的直接问题，而且它与Apache服务器的速度慢/配置错误有关。只需重新启动提供图像的Apache服务器就可以解决我的问题。

ImageIO.read（URL）永远加载图片

1 个答案: