如果轮询不一定返回第一项，并发链接队列是一个不错的选择吗？

Question

我有一个用例，其中队列保存上传项。队列必须是线程安全的。UploadItem有一个方法canUpload（）。UploadItems被添加到尾部的队列中，但是peek（）和poll（）必须返回第一个UploadItem，其中canUpload（）为true。这可能是头部的项目或较新的项目。本质上，我希望项目在准备好上传之前被忽略，并且我希望队列返回准备好的最早的项目。

为了解决这项工作，我扩展了一个并发链接队列，并且我覆盖了 peek（） 和 poll（）。我已经同步了重写的方法，并且我正在使用迭代器来检索第一个有效项目。

public class UploadQueue extends ConcurrentLinkedQueue<UploadItem> {

    public UploadQueue() {}

    @Override public synchronized UploadItem peek() {
        for (UploadItem item : this) {
            if (item.canUpload()) {
                return item;
            }
        }
        return null;
    }

    @Override public synchronized UploadItem poll() {
        for (UploadItem item : this) {
            if (item.canUpload()) {
                remove(item);

                return item;
            }
        }
        return null;
    }

}

这是一个好的实现，还是可以更有效地完成？使用迭代器检索项目是否有任何不良影响？我不能使用索引和 get（） 来选择项目，所以看起来我必须使用迭代器。我也无法跟踪内部变量中的项目，因为它们由外部函数链接和更改。

这将在Android上运行，Android仍然使用Java 6。面对 Java 中的无锁并发链列表和并发链接队列$节点在删除后仍保留在堆中（），是否存在某些 Android 手机可能仍存在 Java 内存泄漏的风险？有谁知道Java是否通常在Android上更新/修补（在其主要版本中）？

Answer 1

将优先级队列与比较器结合使用，该比较器首先在 canUpload 上进行比较，然后在日期的相反顺序上进行比较。

Answer 2

这是一个好的实现方式吗？或者可以更有效地实现吗？

这两个标准并不相互排斥。

此外，如果不知道canUpload的成本有多高，队列会有多大，条目在“不可上传”状态下保持多长时间，就不可能说效率是否可能是一个问题。

然而，当然可以更有效地这样做。例如，如果您可以安排从“不可上载”到“可上载”的转换触发某种类型的事件，那么您可以安排事件处理程序将UploadItem添加到队列中。

对< code>UploadItem对象集合的循环扫描可能比每次从队列的开始扫描更有效。其他可能的策略也可能更有效。

但是这些替代方法也可能会改变上传发生的顺序…如果这对您来说是个问题。

使用迭代器检索项目是否有任何不良影响？

ConprestLinkedQueue的迭代器是弱一致性的。这意味着您不能保证看到在迭代开始后添加的条目。这对您的用例来说可能不是问题。（我认为如果下载偶尔被推迟到下一个队列轮询周期，这并不重要。）

这将在Android上运行，Android仍然使用Java 6。面对Java中的无锁并发链表和ConcurrentLinkedQueue$节点在remove（）后仍保留在堆中，是否存在某些Android手机可能仍然存在Java内存泄漏的风险？

对我来说，这些问题并不意味着长期内存泄漏。如果存在泄漏，那么当线程丢弃迭代器时，看起来可能会被清除……或者类似的东西。

另一方面，那些Q

有人知道Java是否通常在Android上更新/修补（在其主要版本中）？

你不能一概而论。

首先，Java库的Android实现是与标准Oracle / OpenJDK代码库不同的代码库。因此后者的更新/补丁不适用于前者。

其次，即使对标准的Android发行版进行了更新/补丁，也不能保证1）手机制造商会选择它们，2）它们会进入手机公司的分销渠道，或者3）个人智能手机用户会应用它们。