由于构造实例我们忘记处理，我目前在iPojo泄漏方面遇到很多麻烦。我认为这是使用ipojo Factory技术使用命令式实例化的不可避免的缺点：基本上，您是通过调用factory.createComponentInstance(config)指出何时需要服务，因此您有责任说完它。这迫使我保留两个引用，一个用于我要使用的服务，另一个用于iPojo ComponentInstance，以便在使用者完成后可以调用componentInstance.dispose()。如果没有，那就有泄漏
在消费者不需要处理iPojo服务及其实例的生命周期的情况下，还有一种更具声明性的方式来执行此操作吗？
为了简化我的用例，假设有一个带有按钮的UI，并且每次按下按钮时，我需要一个iPojo服务的新的唯一实例。理想情况下，当实例超出范围时将实例化为GC，而无需用户做任何事情
也许我的错误是将服务用作实例，但是我有三个理由使用服务而不是普通类并调用new。
服务展示应可替换
消费者应该依赖于一个接口，而不是一个实现/提供者，这不仅是因为＃1，而且还因为依赖于具体的隐式实现时，会牵扯到更多的传递性依赖关系。
服务impl本身具有一些依赖关系，我希望它们将由iPojo注入（依赖关系注入）。
第二个要求，是否有人知道使用iPojo的任何开源，真实（即非虚拟，演示）项目，我可以以此为例很好地使用iPojo？
最佳答案
除了创建组件实例，您可能应该使用自定义的“创建策略”。因此，您将只有一个组件实例，但将管理多个“实现”实例（服务对象）。您可以决定何时创建和处置这些对象。有关http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/describing-components/providing-osgi-services.html#service-serving-object-creation的更多信息。
关于使用iPOJO的项目，您可以看看依赖于iPOJO的Wisdom Framework：http://wisdom-framework.org（此处提供代码：github.com/wisdom-framework/wisdom/）