总结: 1.在bean初始化前阶段initializeBean()对应的applyBeanPostProcessorsBeforeInitialization()方法中执行完自定义的MyInstantiationAwareBeanPostProcessor的postProcessBeforeInitialization()方法同时会执行CommonAnnotationBeanPostProcessor的postProcessBeforeInitialization方法最后执行@PostConstruct修饰的initPostConstructor方法 2.其他两种bean初始化在invokeInitMethods()中被调用

小马哥，实例化和初始化有什么区别吗？

马哥，请问那个Init（）初始化回调方法视频中是通过xml配置方式定义在Beandefinition中的，如果不用xml配置而采用纯Java配置的话，有没有相应的配置方式呢？

马哥，我梳理一下，希望帮忙评价下是否正确。InstantiationAwareBeanPostProcessor#postProcessBeforeInstantiation应该都是在初始化前回调执行的，只不过容器中如果注册了CommonAnnotationBeanPostProcessor，那么其父类InitDestroyAnnotationBeanPostProcessor中的postProcessBeforeInitialization方法执行的时候，通过findLifecycleMetadata找到标注了@PostConstruct的方法，再通过metadata.invokeInitMethods反射调用标注了@PostConstruct的方法进行初始化操作，而postProcessBeforeInitialization是在applyBeanPostProcessorsBeforeInitialization中回调的，isInitializingBean和自定义初始化方法是在invokeInitMethods中回调的，applyBeanPostProcessorsBeforeInitialization先于invokeInitMethods，所以最终导致了初始化方法的顺序是@PostConstruct->isInitializingBean->自定义初始化方法。而注册的beanPostProcessors顺序很重要，后注册的beanPostProcessors在回调的时候，如果对同一个bean干预它的初始化方式，就会出现后注册的beanPostProcessors覆盖前面的beanPostProcessors。理解的有问题吗？

不太明白为什么要区分实例化与初始化，而且增加折磨多的前后处理方法，起的作用感觉大同小异

老师：：： 有一个疑惑，在spring的初始化阶段，DefaultListAbleBeanFactory中添加 CommonAnnotationBeanPostProcess和MyInistantiationAwareBeanPostProcessor，让他们顺序调换，这样UserHolder的字段属性修改的顺序就不一样了，这个怎么解决。还有就是DefaultListAbleBeanFactory，ApplicationContext在spring的存在关系不是很了解。

为什么 CommonAnnotationBeanPostProcessor 中处理的@PostConstruct 归类成初始化阶段内？从源码上的语意上来看个人觉得归类到初始化前阶段更好理解些。 而注解命名“@PostConstruct” 从命名来看也是很疑惑，感觉没有见名知意。

总结： PostConstruct(非必须)也会在初始化前阶段执行，因为它跟PreDestroy注解一样被CommonAnnotationBeanPostProcessor管理和执行，CommonAnnotationBeanPostProcessor继承了InitDestroyAnnotationBeanPostProcessor，这个继承类实现了BeanPostProcessor接口，在初始化前阶段InitDestroyAnnotationBeanPostProcessor的postProcessBeforeInitialization方法会被调用，这其中就执行了metadata.invokeInitMethods(bean, beanName);这个方法，也就是注解了PostConstruct的方法。

BeanPostProcessor注册有两种方式： 1.ConfigurableBeanFactory. addBeanPostProcessor()手动添加。 手动添加的BeanPostProcessor根据添加的顺序作为执行的顺序； applicationContext.addBeanFactoryPostProcessor(beanFactory -> { beanFactory.addBeanPostProcessor(new MyInstantiationAwareBeanPostProcessor() ); beanFactory.addBeanPostProcessor(new CommonAnnotationBeanPostProcessor() ); }); 2.通过ApplicationContext自动检测：beanFactory.getBeanNamesForType(BeanPostProcessor.class） PostProcessorRegistrationDelegate#registerBeanPostProcessors(ConfigurableListableBeanFactory,AbstractApplicationContext) 执行顺序： priorityOrderedPostProcessors > orderedPostProcessors > nonOrderedPostProcessors（比如MyInstantiationAwareBeanPostProcessor） > internalPostProcessors(比如CommonAnnotationBeanPostProcessor) 手动添加的BeanPostProcessor总是先于自动检测的。 Note, however, that BeanPostProcessor instances added programmatically do not respect the Ordered interface. Here, it is the order of registration that dictates the order of execution. Note also that BeanPostProcessor instances registered programmatically are always processed before those registered through auto-detection, regardless of any explicit ordering.