Java 实时性能

Question

我正在处理需要非常高级的图像处理的 Java 项目。 事实上，我使用 OpenCV 进行大部分操作，并且使用 JNI 来包装我需要的 OpenCV 函数。 我对 OpenCV 提供的性能非常满意，编写 OpenCV 代码的人应该对代码给予极大的赞扬。 与我对 Java 开发人员编写的代码的体验形成鲜明对比。

我开始对我的编程语言的选择持乐观态度，我的项目的第一次工作迭代运行良好，但它的性能远未达到实时（每 2 秒大约 1 帧）。我已经对我的代码进行了一些优化，并且它有很大帮助。 我已经能够将帧速率提高到大约每秒 10-20 帧，这很棒，但我发现要进行任何进一步的优化，我必须重写 Java 代码来完成相同的操作，但 10效率提高 -20 倍。

我对 Java 开发人员很少关注性能感到震惊，尤其是在为媒体相关类编写类时。 我已经下载了 OpenJDK，并且正在探索我正在使用的功能。 例如，Raster 类下有一个名为 getPixels(...) 的函数，它获取图像的像素。 我期望这个函数在源代码中是一个高度优化的函数，通过多次调用 System.arrayCopy 来进一步优化性能。 相反，我发现的是非常“优雅”的代码，他们调用 5-6 个不同的类和 10-20 个不同的方法只是为了完成我可以在一行中完成的操作：

for (int i =0; i < n; i++) {
  long p = rawFrame[i];
  p = (p << 32) >>> 32;
  byte red = (byte) ((p >> 16) & 0xff);
  byte green = (byte) ((p >> 8) & 0xff);
  byte blue = (byte) ((p) & 0xff);
  byte val = (byte)(0.212671f * red + 0.715160f * green + 0.072169f * blue);
  data[i] = val;
  grayFrameData[i] = (val & 0x80) + (val & (0x7f)); 
}

上面的代码将图像转换为灰度并获取浮点像素数据，大约1-10ms。 如果我想对 Java 内置函数执行相同的操作，则转换为灰度本身需要 200-300 毫秒，然后抓取浮动像素大约需要 50-100 毫秒。 这对于实时性能来说是不可接受的。 请注意，为了提高速度，我大量使用了按位运算符，而 Java 开发人员却回避这种操作。

我知道他们需要处理一般情况，但即便如此，他们至少不能提供优化选项，或者至少警告此代码的执行速度有多慢。

我的问题是，在开发的最后阶段（我已经有了我的第一次迭代，而不是我正在开发实时执行更多的第二次迭代）我应该咬紧牙关并切换到 C/C++ 吗？更多地调整事情，或者我应该坚持使用 Java 并希望事情变得更加实时友好，这样我就不必重写已经实现的 Java 代码来获得加速。

我真的开始对 Java 的“优雅”和缓慢感到​​厌恶。 课程数量似乎有点过多。

Answer 1

我不知道您会获得多少性能提升，但如果您有一个长时间运行的进程执行重复的操作，您应该尝试使用 java -server 运行服务器热点虚拟机。 它的性能比 Windows 上默认的客户端 VM 好得多，它针对快速启动时间进行了优化。

Answer 2

目前尚不清楚您是否真的在询问实时性。 实时和真正快速之间是有区别的。 对于真正的快速，考虑平均情况行为就足够了。 吞吐量是主要关注点。 实时意味着每次都能在固定的时间内完成某项任务。 或者当然，有些应用程序需要两者。

在传统的 Java 实现中，例如 OpenJDK，垃圾收集器是实现实时行为的最大问题。 这是因为垃圾收集器可以随时中断程序来完成其工作。 我的公司 aicas 拥有不需要单独线程进行垃圾收集的 Java 实现。 相反，一些 GC 工作是在分配时完成的。 实际上，分配是通过为每个释放的块标记或清除几个块来支付的。 这需要完全重新实现虚拟机。

编译是实时 Java 与传统 Java 实现的另一个不同点。 实时 Java 技术倾向于使用静态或提前 (AoT) 编译而不是 JIT 编译。 JiT 可能适合您的应用程序，因为您可能能够容忍传统 VM 编译最常用的类所需的“预热”时间。 如果是这样，那么您可能没有实时要求，只有吞吐量要求。

如果您有兴趣确保帧解码不会被垃圾收集中断，那么使用 Java 的实时实现以及 AoT 编译可能是有意义的。 Java 实时规范 (RTSJ) 还为实时和嵌入式编程提供其他支持，例如 RelatimeThread、AsyncEventHandler 和 RawMemoryAccess。

当然，要获得良好的性能，无论是实时还是真正快速，都需要关注细节。 过度使用临时对象是没有帮助的。 分配总是需要额外成本，因此应尽量减少。 这对于函数式语言来说是一个重大挑战，因为函数式语言不允许更改对象的状态。 但是，应该注意了解所编写代码的关键路径，以避免不必要的优化。 分析对于了解优化工作最好花在哪里至关重要。

Answer 3

过早的优化是万恶之源。

与其抱怨，不如编写一组优化的库并发布它们，但创建一个针对某些不存在的目标预先优化的“参考”java 实现是错误的。

参考实现的要点是编写易于理解、可维护的代码——它必须如此。 我认为，人们总是希望供应商在必要时分析这个易于理解的版本并重新实现某些部分以提高速度。

Answer 4

除了其他人所说的之外，您还可以为 JDK 贡献优化。 如果您可以提供强大的优化，并且不牺牲通用性或可读性，我希望您能够将您的补丁包含在未来的 JDK 版本中。

因此，您不必希望 JDK 能够变得更好。 您可以帮助实现这一目标。

Answer 5

据我了解，最新版本的 Java（或者可能是 JavaFX）具有允许您访问系统视频硬件中的高级功能的方法。 抱歉，我说得太笼统了，我相信我在 Java Posse 上听说过它，而且由于我陷入了 Java 1.3 的泥潭，所以我从来没有真正有机会去了解一下——但我确实记得听到过类似的事情。

这是关于它的一些内容： 但看起来它只会在 Java 7 中:(

看起来它一开始也只支持播放流和基本的流操作——但也许“等等，Java 会改进”的方法实际上可能有效。

Answer 6

是什么阻止您编写您希望使用的方法的优化版本而不是使用内置方法？ 如果这是不可能的，为什么不使用更原生的语言编写对象，并将其导入到现有的应用程序中呢？

Answer 7

我已经用 Java 完成了计算机视觉工作，我认为它非常适合计算机视觉和实时的东西，你只需要知道如何使用它。

潜在的优化：

如果您需要帮助优化代码，我很乐意提供帮助 - 例如，我可以告诉您，通过创建一个方法

`public static final int getGrayScale(final int pixelRGB){
    return (0.212671f * ((pixelRGB >> 16) & 0xff) + 0.715160f * ((pixelRGB >> 8) & 0xff) + 0.072169f * ((pixelRGB) & 0xff));
}`

并在 for{pixels} 循环中使用它，您可能会获得性能提升。 通过使用方法调用，JVM 可以更大幅度地优化此操作，并且可能还可以更多地优化 for 循环。

如果您有 RAM 需要消耗，您可以为所有可能的 24 位像素像素颜色创建一个静态的最终输出灰度字节查找表。 RAM 中的大小约为 16 MB，但您不必执行任何浮点算术，只需进行一次数组访问。 这可能更快，具体取决于您使用的 JVM，以及它是否可以优化数组边界检查。

寻找类似、更快的图像处理代码的地方：

我强烈建议您查看 ImageJ 图像处理应用程序和应用程序的代码。 它的库，特别是 ij.process.TypeConverter。 就像您的代码一样，它严重依赖于带有位旋转的直接数组操作和最少的额外数组创建。 Java2D 库（标准 JRE 的一部分）和 Java 高级成像 (JAI) 库提供了直接对图像数据快速进行图像处理的其他方法，而无需每次都进行自己的操作。 对于 Java2D，您只需小心使用哪些函数即可。

为什么 Java2D 库如此间接：

大多数“类性”是由于支持多种颜色模型和存储格式（IE HSB 图像、基于浮点的颜色模型、索引颜色模型）。 间接存在是有原因的，有时实际上可以提高性能——BufferedImage 类（例如）直接挂接到最近虚拟机中的图形内存中，以使某些操作更快。 间接让它在很多时候向用户隐藏这一点。

Answer 8

我的问题是，在开发的最后阶段（我已经有了我的第一次迭代，而不是我正在开发实时执行更多的第二次迭代）我是否应该咬紧牙关并切换到 C/C++，其中我可以对事情进行更多的微调，或者我应该坚持使用 Java 并希望事情变得更加实时友好，这样我就不必重写已经实现的 Java 代码来获得加速。

您问我是否应该

1. 切换到能够满足我的性能要求的语言。
2. 坚持使用 Java 并希望事情有所改善。

可能还有其他选择....但选项 2 似乎不太现实，你不能只是“希望”代码变得更快:p

需要注意的几点：

1. OpenJDK 并不一定具有与 Sun 相同的性能JDK，你尝试过Sun JDK吗？
2. 如果您需要在几种方法中完成性能优化，那么可能值得重写它们并坚持使用 Java...

Answer 9

我的建议是，这取决于图像处理相对于整个项目的重要性，以及相对于 java 带来的优势。 显然，如果需要，您可以用 java 编写快速代码（如您所演示的）。 然而，如果您的项目 80% 都包含此类优化，那么我肯定会重新考虑将 Java 作为此处的语言选择。

另一方面，如果这代表了应用程序的 20%，另外 80% 是围绕提供此转换的用户功能，那么也许必须完成操作才能完成操作是值得的权衡，而无需处理使用您自己的内存管理，并拥有 java 为您提供的用于用户交互的任何其他 API（Web、Swing、SWT，无论您使用什么）。

由于垃圾收集器的原因，Java 并不以其实时能力而闻名。 这也可能会咬你，所以要小心。