使用 List<Byte> 不是好主意吗？答案

【问题标题】：Is using List<Byte> not good idea?使用 List<Byte> 不是好主意吗？
【发布时间】：2017-06-19 02:45:33
【问题描述】：

我需要用 Java 重写一些多年前编写的 C++ 代码。

在 C++ 中，我使用 std::vector<unsigned char> buffer 来实现一个缓冲区，我将从套接字连接中检索该缓冲区。

使用这个缓冲区，我可以进行各种操作：

有一个迭代器来缓冲元素并根据需要推进它。
搜索某些令牌。
使用索引/迭代器从缓冲区中获取一系列字节元素（子缓冲区）。

基于这些要求，我可以使用ArrayList<Byte> 并拥有一个自定义的类似迭代器的类来跟踪当前元素并使用索引工作。

在哪些方面使用List<Byte>会效率低？

我在其他地方看到过ByteBuffer 被推荐，但我的要求并不需要它。

也许是因为我需要索引、执行搜索等，而且我的缓冲区一旦创建就不会更改或修改。

我只需要读取缓冲区并执行上述操作。

我是否应该更好地使用我自己的迭代器/指针类对 byte[] 进行包装？

【问题讨论】：

ArrayList 不需要自定义的类似迭代器的类，因为有一个类，您可以使用iterator() 获得它（或者您可以在Java 8+ 中使用stream()）。如果您不提前知道缓冲区大小，首选ArrayList，ByteBuffer 更快更高效（但需要您知道大小）。
问题是我无法将迭代器向前推进 10 到 20 步（使用循环似乎很糟糕），这就是为什么我认为我可以只使用索引编写一个自定义的。由于我根本没有修改缓冲区并且需要进行搜索，所以ByteBuffer 似乎也没有必要。
不，说真的，使用ByteBuffer。不管您需要什么操作，ArrayList<Byte> 的效率都会低得令人尴尬。修改、搜索什么的，都没关系。
@LouisWasserman：我猜是因为它包含对Byte 对象的引用，这些对象在堆上随机分布，而ByteBuffer 包含连续字节？
它们可能不是随机分布的，，但是任何额外的堆间接寻址都比你需要的成本要高得多。

标签： java c++ iterator

【解决方案1】：

这真的取决于您的要求。 List<Byte> 的最大问题是您使用的是 Byte 对象而不是原始的 byte 值！

这不仅会影响内存消耗，还意味着可能会出现很多boxing/unboxing。这可能会导致生成大量对象^† - 导致垃圾收集器不断流失。

因此，如果您打算进行密集计算，或者您正在处理大量数据，那么ByteBuffer 类在这里具有各种性能优势。

^{† 来自Java Language Specification §5.1.1}

^{上面的规则是一个务实的妥协，要求某些共同的价值观总是被装进无法区分的对象中。实现可能会延迟或急切地缓存这些内容。}

【讨论】：

我正在考虑使用我自己的迭代器对byte[] 进行包装，因为我没有修改缓冲区，只是检索和搜索它。如果我错过了，你能搜索ByteBuffer吗？
@cpx 可以，你可以通过ByteBuffer#position(int)设置你想开始读/写的位置。

【解决方案2】：

List 不是一个类，它是一个接口，所以你需要在它后面提供一个实际的类来提供一个实现。您可以在代码中使用 List<Byte> 变量，以隐藏您正在使用的实际类的实现细节，但如果您有时需要它作为数组的行为，并且作为其他列表（whit 迭代器等），那么您无需放弃ArrayList<Byte> 类并继续使用它，即可同时使用索引和列表行为。如果您切换到List<Byte>，最后您将结束不必要的强制转换来访问ArrayList 的数组功能，这些将消耗cpu，检查是否正在强制转换正确的类。你会模糊代码。此外，正如其他回复所建议的那样，您在 ByteBuffer 或 CharBuffer 中还有其他选择。但请注意，这些类是abstract，因此您必须先实现其中的一部分，然后才能使用。

【讨论】：

"但是要注意这些类是抽象的，所以你必须先实现它们的一部分，然后才能使用" - Not at all: ByteBuffer buffer = ByteBuffer.allocate(1024);