问OSGi性能调试

EN

这里有一些常见的设计陷阱，希望这能有所帮助：

• 创建线程可能是非常“昂贵”的。例如，你有不断创建新线程的消息吗？使用线程池。
• 同样适用于对象(例如，消息、测量)，特别是在只有一个字段发生变化的重型包装器中。使用对象池-它有很大的帮助！
• 在使用字符串时要非常小心，尤其是连接。在字符串上调用简单的操作(替换、追加、复制)经常涉及到许多临时对象的使用，这对内存和垃圾回收都有负面影响。当在经常执行的代码中修改字符串时(例如，日志帮助器类的通用方法，负责编写通过协议发送的消息的方法，等等)然后，优化将无效方法替换为不使用临时对象的实现，从而显着提高性能。

- Use `StringBuffer`
- Use own String parsing via `String.indexOf(int)` instead of `StringTokenizer` whenever possible
- First char comparison via `string.charAt(0)` is faster than `String.startsWith(str)`
- Use `String`’s equals method instead of `equalsIgnoreCase` whenever possible

​

• 调整日志级别，使其在正常工作期间不包括调试消息。所有这些调试消息的简单创建可能会显著降低系统速度。同时输出到控制台(即使您看不到)通常会减慢系统速度-始终记录到OSGi日志服务。

您发布的分析显示了许多字符串。因此，您可能会遇到一个旧的Java性能陷阱。

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

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