在非web应用程序中使用BeanFactory，因为它只支持单例和原型bean作用域。

而ApplicationContext容器确实支持所有的bean作用域，所以你应该将它用于web应用程序。

为了补充Miguel Ping回答的问题，这里是文档中的另一个部分，也回答了这个问题:

简短的版本:使用ApplicationContext，除非你有很好的理由不这样做。对于那些想要更深入地了解上述建议的“但是为什么”的人，请继续阅读。

(将这篇文章发布给未来可能会读到这个问题的春季新手)

BeanFactory和ApplicationContext的区别如下:

BeanFactory uses lazy initialization but ApplicationContext uses eager initialization. In case of BeanFactory, bean is created when you call getBeans() method, but bean is created upfront in case of ApplicationContext when the ApplicationContext object is created. BeanFactory explicitly provide a resource object using syntax but ApplicationContext creates and manages resource objects on its own. BeanFactory doesnt support internatiolization but ApplicationContext supports internationalization. With BeanFactory annotation based dependency injection is not supported but annotation based dependency injection is supported in ApplicationContext.

使用BeanFactory:

BeanFactory beanfactory = new XMLBeanFactory(new FileSystemResource("spring.xml"));
 Triangle triangle =(Triangle)beanFactory.getBean("triangle");

使用ApplicationContext:

ApplicationContext context = new ClassPathXMLApplicationContext("spring.xml")
Triangle triangle =(Triangle)context.getBean("triangle");

基本上我们可以用两种方式创建spring容器对象

使用BeanFactory。 使用ApplicationContext。

都是界面，

使用实现类，我们可以为spring容器创建对象

来看看区别

BeanFactory:

不支持基于注释的依赖注入。 不支持I18N。 默认情况下，它支持惰性加载。 它不允许配置到多个配置文件。

例如：BeanFactory context=new XmlBeanFactory（new Resource（“applicationContext.xml”））;

ApplicationContext

支持基于注释的依赖注入。@ autowired, @PreDestroy I18N支持 它默认支持侵略性加载。 它允许配置多个配置文件。

前任： ApplicationContext context=new ClasspathXmlApplicationContext（“applicationContext.xml”）;

BeanFactory和ApplicationContext都是从spring IOC容器中获取bean的方法，但仍有一些区别。

BeanFactory是实例化、配置和管理许多bean的实际容器。这些bean通常彼此协作，因此它们之间存在依赖关系。这些依赖关系反映在BeanFactory使用的配置数据中。

BeanFactory和ApplicationContext都是Java接口，而ApplicationContext扩展了BeanFactory。它们都是使用XML配置文件进行配置的。简而言之，BeanFactory提供了基本的控制反转(IoC)和依赖注入(DI)特性，而ApplicationContext提供了高级特性。

BeanFactory由接口“org.springframework.beans”表示。其中BeanFactory有多个实现。

ClassPathResource resource = new ClassPathResource("appConfig.xml");
XmlBeanFactory factory = new XmlBeanFactory(resource);

区别

BeanFactory instantiate bean when you call getBean() method while ApplicationContext instantiate Singleton bean when container is started, It doesn't wait for getBean() to be called. BeanFactory doesn't provide support for internationalization but ApplicationContext provides support for it. Another difference between BeanFactory vs ApplicationContext is ability to publish event to beans that are registered as listener. One of the popular implementation of BeanFactory interface is XMLBeanFactory while one of the popular implementation of ApplicationContext interface is ClassPathXmlApplicationContext. If you are using auto wiring and using BeanFactory than you need to register AutoWiredBeanPostProcessor using API which you can configure in XML if you are using ApplicationContext. In summary BeanFactory is OK for testing and non production use but ApplicationContext is more feature rich container implementation and should be favored over BeanFactory BeanFactory by default its support Lazy loading and ApplicationContext by default support Aggresive loading.

对我来说，选择BeanFactory而不是ApplicationContext的主要区别似乎是ApplicationContext将预先实例化所有的bean。来自Spring文档:

Spring sets properties and resolves dependencies as late as possible, when the bean is actually created. This means that a Spring container which has loaded correctly can later generate an exception when you request an object if there is a problem creating that object or one of its dependencies. For example, the bean throws an exception as a result of a missing or invalid property. This potentially delayed visibility of some configuration issues is why ApplicationContext implementations by default pre-instantiate singleton beans. At the cost of some upfront time and memory to create these beans before they are actually needed, you discover configuration issues when the ApplicationContext is created, not later. You can still override this default behavior so that singleton beans will lazy-initialize, rather than be pre-instantiated.

考虑到这一点，我最初选择BeanFactory用于集成/性能测试，因为我不想加载整个应用程序来测试孤立的bean。但是——如果我说错了，有人会纠正我——BeanFactory不支持类路径XML配置。因此，BeanFactory和ApplicationContext都提供了我想要的关键特性，但两者都没有。

据我所知，文档中关于覆盖默认实例化行为的说明发生在配置中，而且它是每个bean的，所以我不能在XML文件中设置“lazy-init”属性，否则我就不得不维护一个版本用于测试，另一个版本用于部署。

我最终所做的是扩展ClassPathXmlApplicationContext以惰性加载bean以在测试中使用，如下所示:

public class LazyLoadingXmlApplicationContext extends ClassPathXmlApplicationContext {

    public LazyLoadingXmlApplicationContext(String[] configLocations) {
        super(configLocations);
    }

    /**
     * Upon loading bean definitions, force beans to be lazy-initialized.
     * @see org.springframework.context.support.AbstractXmlApplicationContext#loadBeanDefinitions(org.springframework.beans.factory.xml.XmlBeanDefinitionReader)
     */

    @Override
    protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException {
        super.loadBeanDefinitions(reader);
        for (String name: reader.getBeanFactory().getBeanDefinitionNames()) {
            AbstractBeanDefinition beanDefinition = (AbstractBeanDefinition) reader.getBeanFactory().getBeanDefinition(name);
            beanDefinition.setLazyInit(true);
        }
    }

}