JavaPOJO—在迭代新数据收集后回收缓存的哈希表值

所以，是的，我只是想看看是否有一种更优雅的方式来完成我下面要做的事情。请记住，我想要的是与POJO普通的旧Java对象相关的答案，因为这个问题与J2ME相关，所以只有Java 1.5及以上版本才有泛型和现代数据结构：

假设我有一个对象MyImage，它只是一个简单的bean对象，通过对服务器的网络调用填充数据。它包含的只是与我的应用程序相关的图像的元数据，更重要的是，它包含一个唯一标识符，用于构造URL，以便从我的服务器获取该对象的图像。当我为这些对象发出请求时，我经常会收到一组新的对象，其中一些与以前的请求相同

现在，尽管我能够下载图像，但问题在于如何缓存图像数据，当我接收到一组新的MyImage对象时，我将它们与缓存进行交叉引用，并且仅在该MyImage对象已经下载的情况下保留该对象的图像。换句话说，当我将下载的图像保存到哈希表缓存中时，我使用构造的URL my_image_SERVER+myImageUniqueId为图像数据键入关键字。当我获得一组新的MyImage对象时，当前我会执行以下操作：

 Hashtable imgs = getImages();

 //If we have cached images, we should see which ones to carry over.
 if(imgs.size() > 0){       
    Hashtable newImgs = new Hashtable();
    for(int i = 0; i < myImages.length; i++){
        MyImage mi = myImages[i];
        if(mi != null && mi.hasImage()){
            //Check if we have the MD5 URL
            if(imgs.containsKey(IMG_URL_PATH + mi.getUniqueId())){
                //Place in new hashtable
                newImgs.put(IMG_URL_PATH + mi.getUniqueId(), imgs.get(IMG_URL_PATH + mi.getUniqueId()));
            }
        }
    }
   _bannerImgs = newImgs;
 }

我想知道这听起来是否合法，或者可以用一种更有效的方式来做吗？

后续

基于下面注释中代码的假定用途，您的做法似乎是合理的，但是您可以进行一些小的优化。将代码的相关部分更改为：

    // Check if we have the image in our cache
    String key = IMG_URL_PATH + mi.getUniqueId();
    Object image = imgs.get(key);
    if (image != null) {
        // Carry over to new cache
        newImgs.put(key, image);
    }

注:

创建/使用局部变量可避免创建键字符串3次。 使用get而不是contains可以消除一个哈希表查找。 然而，这是否会对您的系统的性能产生重大影响是值得怀疑的。。。除非getUniqueId方法做了一些愚蠢的事情，比如每次调用它时计算MD5和。但显然不是

---

尽管性能如此，我还是会做出这样的更改，因为它使代码更易于阅读。。。IMO.

如果您已经有一套包含要保留的图像键，那么您可以简单地执行以下操作：

imgs.keySet().retainAll(stillValidKeys);

---

但是，如果您只有一个列表，那么您当前的代码可能就足够了。

代码将用一个只包含要保留的图像的新缓存替换旧缓存。因此，它正在删减旧的cache.FYI，uniqueId的值是预先确定的，并且是一成不变的，所有这些计算都是在后端对返回的每个图像进行的。不幸的是，由于J2ME/CLDC使用的是简单的Java旧版本，因此不支持set对象，因此该函数在我的情况下不起作用。