请遵循以下方法：
BeanPostProcessorChecker
在你的IDE中打开（这是的内部类AbstractApplicationContext
）if (logger.isInfoEnabled())
{在方法上设置一个断点postProcessAfterInitialization
- 运行你的代码
- 当你达到断点时，
getBean(String,Class<T>)
在堆栈跟踪中查找对的调用。
这些调用之一将尝试创建一个
BeanPostProcessor。那个豆应该是罪魁祸首。
背景
想象一下这种情况：
public class FooPP implements BeanPostProcessor { @Autowire private Config config;}当必须创建Spring时
config（因为它是的依赖项
FooPP），它有一个问题：合同规定
BeanPostProcessor必须将所有内容应用于所创建的每个bean。但是当Spring需要时
config，至少有一个PP（即
FooPP）尚未准备好服务！
当你使用
@Configuration类定义此bean 时，情况会变得更糟：
@Configurationpublic class BadSpringConfig { @Lazy @Bean public Config config() { return new Config(); } @Lazy @Bean public FooPP fooPP() { return new FooPP(); }}每个配置类都是一个bean。这意味着要从中建立一个bean工厂
BadSpringConfig，Spring需要应用后处理器，
fooPP但是为此，它首先需要bean工厂…
在此示例中，可以打破循环依赖之一。你可以
FooPP实现
BeanFactoryAware让Spring注入
BeanFactory到后处理器。这样，你就不需要自动装配。
在代码的后面，你可以请求bean：
private LazyInit<Config> helper = new LazyInit<Config>() { @Override protected InjectionHelper computevalue() { return beanFactory.getBean( Config.class ); }};@Overridepublic Object postProcessBeforeInitialization( Object bean, String beanName ) throws BeansException { String value = helper.get().getConfig(...);}
