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

例子:

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

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

为清晰起见，经过编辑。OSGi页面给出了一个比我更好的简单答案

一个简单的答案:OSGi服务平台为协作网络服务提供了一个标准化的、面向组件的计算环境。这种体系结构显著降低了构建、维护和部署应用程序的整体复杂性。 OSGi服务平台提供了在各种网络的设备上动态改变组合的功能，不需要重新启动。

在单个应用程序结构中，比如Eclipse IDE，在安装新插件时重新启动并不是什么大问题。完全使用OSGi实现，您应该能够在运行时添加插件，获得新功能，而完全不需要重新启动eclipse。

同样，这不是每天都要做的大事，只是应用程序的小用途。

但是，当你开始研究多计算机、分布式应用框架时，这就是它开始变得有趣的地方。当关键系统必须有100%的正常运行时间时，热插拔组件或在运行时添加新功能的能力非常有用。当然，现在大多数情况下都有这样做的能力，但是OSGi正试图将所有东西捆绑到一个具有公共接口的漂亮的小框架中。

OSGi能解决常见问题吗，我不确定。我的意思是，它可以，但对于更简单的问题，开销可能不值得。但是当您开始处理更大的、网络化的应用程序时，需要考虑这一点。

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

例子:

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

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

我发现OSGi有以下好处:

每个插件都是一个版本化的工件，它有自己的类加载器。 每个插件都依赖于它所包含的特定jar和其他特定版本的插件。 由于版本控制和隔离的类加载器，同一工件的不同版本可以同时加载。如果应用程序的一个组件依赖于插件的一个版本，而另一个组件依赖于另一个版本，那么它们可以同时加载。

这样，您就可以将应用程序构建为一组按需加载的版本化插件构件。每个插件都是一个独立的组件。就像Maven帮助您构建构建，使其可重复，并由创建它的工件的一组特定版本定义一样，OSGi帮助您在运行时完成这一点。

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

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

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

3)集群。

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

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

它重新启动。

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?

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