在它的官方网站上已经有了一个很有说服力的声明，我可以引用

OSGi技术如此成功的关键原因是它提供了一个非常成熟的组件系统，实际上可以在数量惊人的环境中工作。OSGi组件系统实际上用于构建高度复杂的应用程序，如ide (Eclipse)、应用服务器(GlassFish、IBM Websphere、Oracle/BEA Weblogic、Jonas、JBoss)、应用程序框架(Spring、Guice)、工业自动化、住宅网关、电话等等。

至于开发商的利益?

开发人员:OSGi通过为当今大规模分布式系统和小型嵌入式应用程序提供模块化体系结构来降低复杂性。从内部和现成的模块构建系统可以显著降低复杂性，从而降低开发和维护费用。OSGi编程模型实现了基于组件的系统的承诺。

请参阅使用OSGi的好处。

OSGi会让你的代码莫名其妙地抛出NoClassDefFoundError和ClassNotFoundException(很可能是因为你忘了在OSGi配置文件中导出一个包);因为它有类加载器，它可以使你的类com.example.Foo不能转换为com.example.Foo，因为它实际上是由两个不同的类加载器加载的两个不同的类。它可以在安装Eclipse插件后将Eclipse引导到OSGi控制台。

对我来说，OSGi只是增加了复杂性(因为它为我增加了一个心理模型)，因为异常而增加了烦恼;我从未真正需要它“提供”的活力。它是侵入式的，因为它需要为所有模块配置OSGi包;这绝对不简单(在一个更大的项目中)。

因为我的糟糕经历，我倾向于远离那个怪物，非常感谢。我宁愿忍受jar依赖的地狱，因为这比OSGi引入的类加载器地狱更容易理解。

在OSGi上让我抓狂的几件事:

1)实现和它们的上下文加载器有很多怪癖，并且可能有点异步(我们在confluence中使用felix)。与纯spring(没有DM)相比，[main]几乎运行了所有同步。

2)热加载后类不相等。例如，在hibernate上有一个tangosol缓存层。它被Fork.class填充，在OSGi作用域之外。你热加载了一个新的罐子，Fork没有改变。Class[Fork] != Class[Fork]。由于相同的潜在原因，它也会在序列化过程中出现。

3)集群。

您可以解决这些问题，但这是一个非常麻烦的问题，并且会使您的体系结构看起来有缺陷。

对于那些为热插拔做广告的人。OSGi的#1客户端?Eclipse。Eclipse在加载包之后做什么?

它重新启动。

You can, analogically speaking, change the motor of your car without turning it off. You can customize complex systems for the customers. See the power of Eclipse. You can reuse entire components. Better than just objects. You use a stable platform to develop component based Applications. The benefits of this are huge. You can build Components with the black box concept. Other components don't need to know about hidden interfaces, them see just the published interfaces. You can use in the same system several equal components, but in different releases, without compromise the application. OSGi solves the Jar Hell problem. With OSGi you develop thinking to architect systems with CBD

对于使用Java的每个人来说，有很多好处(我现在只提醒了这些)。

I don't care too much about the hotplugability of OSGi modules (at least currently). It's more the enforced modularity. Not having millions of "public" classes available on the classpath at any time protects well from circular dependencies: You have to really think about your public interfaces - not just in terms of the java language construct "public", but in terms of your library/module: What (exactly) are the components, that you want to make available for others? What (exactly) are the interfaces (of other modules) you really need to implement your functionality?

这很好，热插拔是附带的，但我宁愿重新启动我通常的应用程序，而不是测试所有的热插拔组合…

如果基于Java的应用程序需要添加或删除模块(扩展应用程序的基本功能)，而不需要关闭JVM，则可以使用OSGI。通常，如果关闭JVM的成本比较高，那么仅仅是为了更新或增强功能。

例子:

Eclipse:为插件的安装、卸载、更新和相互依赖提供了平台。 AEM: WCM应用程序，其中功能更改将由业务驱动，无法承担维护停机时间。

注意:Spring框架停止支持OSGI Spring包，认为它对于基于事务的应用程序或这些行中的某些点来说是不必要的复杂性。我个人是不会考虑OSGI的，除非绝对必要，比如在构建平台这样的大项目中。