OSGi 性能调试答案

【问题标题】：OSGi performance debuggingOSGi 性能调试
【发布时间】：2012-05-26 18:17:24
【问题描述】：

我正在尝试诊断基于 OSGi 构建的 Java 应用程序的性能问题。该平台是在嵌入式 Linux 机器上运行的 ARM5 处理器。 CPU 利用率通常为 100%，内存消耗量很大。

我在公司的嵌入式 O/S 方面，Java 开发人员在企业应用程序开发方面比嵌入式更熟练。虽然我的背景还包括嵌入式 Java，但正是因为这个原因，我才避免使用 OSGi。

我正在寻找唾手可得的成果 - 有哪些常见的设计错误可能会导致 CPU 和内存消耗过多，我可以快速调查这些错误以使 CPU 利用率恢复到更合理的水平。

【问题讨论】：

我们需要更多信息；您正在使用哪个 OSGi 实现？菲利克斯？鲢鱼？春分？您正在使用哪种 ARM JVM 实现？热点？爪哇我？ IBM J9 ?此外，您的问题可能需要分析，而不是调试。
我将不得不向开发人员询问正在使用的 OSGI 实现，但我怀疑这甚至不相关——这似乎是一个独立于所有低级细节的问题。我想我知道一些问题出在哪里——这是一个实时应用程序，我怀疑 Java 代码没有解决被请求和处理的数据的及时性。
如果您认为问题与 OSGi 有关，那么使用哪个 OSGi 实现非常相关......但是我倾向于同意 OSGi 不太可能相关。我将从查看较低级别的 Java 问题开始，例如 GC。你能附上一个分析器吗？如果真实设备不支持，那么您可以在台式计算机上运行它并在那里对其进行配置吗？等等……
Neil，开发人员确实在 Windows 机器上对其进行了分析，最大的内存消耗是数千个字符串，所有字符串都与 OSGi 包及其名称相关联。那台机器太快了，无法发生 CPU 争用。这是一个 256MB 的 ARM5 机器，并且 MB 字符串之上的 MB 并不完全适合嵌入式 Linux。我可以访问一些更快的（400MHz），但在内存和盒子上仍然很小，并且正在考虑将应用程序放在其中一个上并查看它真正需要多少 CPU，然后进行分析。

【解决方案1】：

以下是一些常见的设计陷阱，希望对您有所帮助：

线程的创建可能非常“昂贵”。你有没有例如不断创建新线程的消息传递？使用线程池。
对于对象（例如消息、测量值）也是如此，尤其是内部只有一个字段发生变化的重型包装器。使用对象池 - 它有很多帮助！
对字符串要非常小心，尤其是串联。对字符串调用简单的操作（替换、追加、复制）通常会涉及到“表面之下”的许多临时对象的使用，这对内存和垃圾回收都有负面影响。当在经常执行的代码中对字符串进行修改时（例如，日志助手类的常用方法、负责编写通过协议发送的消息的方法等），然后用不使用的实现替换无效方法的优化临时对象显着提高了性能。
- 使用StringBuffer
- 尽可能通过String.indexOf(int)而不是StringTokenizer使用自己的字符串解析
- 通过string.charAt(0) 进行的第一个字符比较比String.startsWith(str) 快
- 尽可能使用String的equals方法而不是equalsIgnoreCase
调整日志级别，使其在正常工作期间不包含调试消息。所有这些调试消息的简单创建可能会大大降低系统速度。还输出到控制台（即使您没有看到它）通常会减慢系统速度 - 始终改为登录到 OSGi 日志服务。

【讨论】：

当我和开发人员查看对象转储时，字符串都是由 OSGi 创建的。这就是为什么我觉得这是一个 OSGi 问题。我最近确实看到了其他东西，那就是一些 ConcurrentModificationException。如果应该从某种集合中删除对象，并且异常导致对象被抛在后面，这将解释我所看到的许多事情。正如我所说，我在房子的 O/S 一侧，所以要在大楼里漫步很长一段时间才能在开发人员立方体中进行 plotz。而嵌入式 Linux 的工作人员已经忙了 6 周了……
很抱歉迟到了投票和接受。从长远来看，该软件被证明对于该设备来说是无法使用的臃肿，并且所有这些都被丢弃了。但上面的建议是为了让这一切顺利进行而进行的一些尝试。

【解决方案2】：

您发布的分析显示了很多字符串。所以也许你遇到了一个旧的 Java 性能陷阱。

如果您在代码中的某个地方这样做： myString = myString + " ";或类似的循环它每次都会创建一个新对象。在这些情况下，使用 StringBuilder 是有意义的。这只是一个疯狂的猜测，但它也击中了我。

【讨论】：

【解决方案3】：

试试 Knopflerfish，他们有一个更专注于嵌入式的开源框架实现。还有一家 Prosyst 公司有一个针对嵌入式的商业 OSGi 框架。

【讨论】：