Java OSGi和性能？

OSGi

是否适用于高性能应用服务器

OSGi

有助于生成高度模块化的应用程序，但由于执行模型不同于常规Java应用程序（因为我知道

OSGi

应用程序在特定平台上运行，如

Apache Felix

）

在性能方面，您对不同的实现有哪些经验

---

谢谢

您可能需要计算框架的特定启动时间，但在运行时，它对性能的影响基本为零，因为简而言之，它只是类加载

相当多的现代应用服务器使用OSGi实现作为基础（例如JBoss、WebSphere、WebLogic、GlassFish），因此您可以确保它的可靠性和性能。

---

请参阅此参考列表：

根据我的经验，将应用程序从非OSGi环境移动到OSGi环境（使用Felix）对性能没有影响。我生产的每个产品都要经过压力测试；压力测试结果表明，性能没有下降

这可能取决于应用程序的功能。我将不考虑明确的OSGi概念，例如服务，因为这类新代码需要您自己的测试，并且我假设您正在询问对现有POJO代码的影响

OSGi环境的隐含影响主要是类加载。正如您可能知道的，OSGi为每个bundle指定了单独的类装入器，并提供了一种将bundle中的代码连接到其他bundle中的依赖项的方法。当一个包中的类调用另一个包中的类时，第二个包的类加载器负责加载第二个类

与普通Java环境中使用的默认类装入器相比，这个类装入逻辑可能（但可能不会）会消耗一些额外的工作。但是，除非您的代码本身不断地重新创建和重新加载类（这是不可能的），否则任何性能影响都可能是可以忽略的。无论如何，这只是一种理论上的可能性。这取决于您选择的实现是否尽可能高效

对内存占用的影响也很小。最好使用堆转储并使用类似mat的东西来分析这一点

---

相信我，您将花费更多的时间了解OSGi的概念、OSGi容器、工具、版本管理之间的差异，而不是等待类加载；）

由于类加载速度加快，OSGi可能会导致非常小的性能提高。由于有多个类加载器，这也会导致内存消耗的微小增加

---

与您问题中的断言相反：OSGi不会改变Java执行模型

对类加载性能的影响，我认为OSGi对传统类加载模型的影响通常不是很大

我认为有两个因素支持和反对OSGi。有一个事先“惩罚”你招致你通常不会，这是解决阶段。需要解析捆绑包，并连接它们的依赖关系。还有其他复杂因素，如DynamicPort包等

---

然后是实际的类加载性能。这就是OSGi可能获胜的地方。在OSGi类加载的情况下，对于已经连接好的依赖项，这是一个非常简单的委托。在传统类加载的情况下，这将是对全局类路径的线性搜索。这将适用于您加载的每一个类。

我想说，除非您将类加载考虑在内，否则不会有性能损失，但只有在您添加新模块（服务）或启动框架时才会发生。也许设计模块化的应用程序会导致性能比其他架构有所下降，但这通常不被考虑，因为这是java，而且你可以制作一个24/7工作的应用程序，这是OSGi的全部目的，那么你肯定可以牺牲一点点性能（我会说）。

改编的含义是什么？@Edmondo1984我的意思是，您是否建议将OSGi用于高性能应用程序服务器。OSGi中有更多的类加载器并不一定意味着它会变慢。事实上，如果您遵循每个包都有自己的类加载器的思想过程，这也意味着每个包只需要从比传统java类路径大小小（几个）数量级的资源子集执行类加载器查找。每个bundle都应该能够非常快速地完成类加载，因此在考虑性能时，很难将“多类加载器”arg用作缺点。实际上，每一个包都会更加灵活。我并不是说它会变得更慢。我说“可能是这个类加载逻辑消耗了一些额外的工作”。同样，也可能是工作量减少了。我试图不作承诺，因为除非知道OSGi实现，否则任何一种方法都无法给出实际的答案。每增加一层都会带来一些性能损失，这在大多数情况下通常是正确的。将应用程序设计为高度模块化会在设计和维护方面带来很多好处，但增加的抽象级别会在执行时间和空间方面降低一些性能。虽然在大多数应用程序中，特别是面向对象的应用程序具有良好的设计和高可维护性，但它被认为比几毫秒和几兆字节要好。每一层都会增加一些东西，但不一定要提高性能。例如，缓存层增加了复杂性和内存消耗，但显著提高了性能。此外，更好的设计会导致更好的理解和更少的复制，从而允许开发人员进行重用，这是不可能的