java.nio.charset.Charset.decode(..)/encode(..)的快速替代品

Question

有人知道做java.nio.charset.Charset.decode(..)/encode(..)的更快的方法吗？

这是我目前使用的一项技术的瓶颈之一。

具体地说，在我的应用程序中，我将一个部分从Java解决方案更改为JNI解决方案(因为有一种C++技术比我使用的Java技术更适合我的需求)。

这一变化带来了一些显着的速度下降(以及cpu和内存使用率的显著增加)。

深入了解我使用的JNI解决方案，java应用程序通过byte[]与C++应用程序通信。这些byte[]由Charset.encode(..)生成。并传递到C++端。然后，当C++使用byte[]进行响应时，它将在Java端通过Charset.decode(..)进行解码。

在分析器上运行它，我发现Charset.decode(..)和Charset.encode(..)与JNI解决方案的整个执行时间相比，这两个解决方案都花费了相当长的时间(我只分析了JNI解决方案，因为它是我可以很快完成的。一旦我的日程安排有空，我将在以后的日期分析整个应用程序:-) )。

进一步了解我的问题后，似乎这是Charset.encode(..)的一个已知问题。和解码(..)这个问题正在Java7中得到解决。然而，由于一些限制，迁移到Java7对我来说(目前)不是一个选择。

这就是为什么我在这里询问是否有人知道Java5解决方案/替代方案(对不起，应该早点提到这是针对Java5的)？:-)

Answer 1

用于encode()和decode()的javadoc清楚地表明，这些是方便的方法。例如，对于encode()

将Unicode字符编码为此字符集的字节的

便捷方法。

对字符集cs调用此方法将返回与表达式相同的结果

 cs.newEncoder()
   .onMalformedInput(CodingErrorAction.REPLACE)
   .onUnmappableCharacter(CodingErrorAction.REPLACE)
   .encode(bb); 

，但它可能更高效，因为它可以在连续的调用之间缓存编码器。

这里的语言有点模糊，但如果不使用这些方便的方法，您可能会获得性能提升。创建并配置编码器一次，然后重用它：

 CharsetEncoder encoder = cs.newEncoder()
   .onMalformedInput(CodingErrorAction.REPLACE)
   .onUnmappableCharacter(CodingErrorAction.REPLACE);

 encoder.encode(...);
 encoder.encode(...);
 encoder.encode(...);
 encoder.encode(...);

阅读javadoc总是值得的，即使你认为你已经知道了答案。

Answer 2

第一部分-将数组传递到JNI代码中通常不是一个好主意。由于GC，Java必须复制数组。在worth案例中，数组将被复制两次-在JNI代码中和在返回的过程中:)

正因为如此，引入了Buffer类层次结构。当然，Java开发团队创建了一种很好的编码/解码字符的方法：

Charser#newDecoder将返回CharsetDecoder，它可用于根据Charset将ByteBuffer转换为CharBuffer。有两个主要的方法版本：

CoderResult decode(ByteBuffer in, CharBuffer out, boolean endOfInput)
CharBuffer decode(ByteBuffer in)

为了获得最大的性能，你需要第一个。它内部没有隐藏的内存分配。

你需要注意的是，编码器/解码器可以维护内部状态，所以要小心(例如，如果你从2个字节的编码中映射，而输入缓冲区有一半的字符...)。编码器/解码器也不是threadsafe

Answer 3

在字节数组中“压缩”字符串的理由很少。我建议编写以utf-16字符串作为参数的C函数。这种方式不需要任何转换。