BeanFactoryPostProcessor vs BeanPostProcessor

BeanFactoryPostProcessors affect BeanDefinition objects because they are run right after your configuration is read in.There are no bean instances created yet.

So it can’t do anything to your objects instances yet. For Example the PropertyPlaceholderConfigurer is a BeanFactoryPostProcessor, which looks through the

BeanDefinition objects and replaces any ${property.name} with the actual value of property.name from a Properties file, or System.getProperty() or environment variables.

例如：

PropertyPlaceholderConfigurer

EntityManagerBeanDefinitionRegistrarPostProcessor

BeanPostProcessors affect instances of your objects.

For example here is where Spring AOP decides to create proxies for your beans.

So you declare transactions or AOP Aspect JoinPoints to run code when certain methods are called on your beans.

Well how is Spring going to add that “Code” to your code. It uses proxies. So when you call your business logic method, you want it to start a transaction.

So in the BeanPostProcessing phase, Spring will see that you defined transactions on that method, it will create a Proxy object and wrap it around your actual

bean instance, and it will put the Proxy object into the ApplicationContext/BeanFactory’s HashMap under the beans name.

So now when you call getBean() what you get back isn’t the actual Bean Instance, but the Proxy instead that holds the actual bean Instance.

Without the BeanPostProcessor phase, Spring would not be able to do that.

出处：

BeanFactoryPostProcessor vs BeanPostProcessor

深入Spring Boot：那些注入不了的 Spring 占位符