概念
Context也就是我们常说的spring容器，打个比方，context就像是一家公司，beans则是公司的工厂，除了工厂，公司还有翻译，仓库以及办公场所等等。
下面就看看context的主要构成部件。
Context构成部件
上图是ApplicationContext的实体静态结构，它继承了六个实体。虽然是继承，但其实context和他们的关系更像是聚合。Spring使用继承主要是为了在context上也同时体现这6个实体的特征。在实现层面，context事实上是个包装类，最终通过聚合的实体类完成相应行为，而ApplicationContext接口本身并没有什么实质意义的方法。
public interface ApplicationContext extends EnvironmentCapable, ListableBeanFactory, HierarchicalBeanFactory,
MessageSource, ApplicationEventPublisher, ResourcePatternResolver {
String getId();
String getApplicationName();
String getDisplayName();
long getStartupDate();
ApplicationContext getParent();
AutowireCapableBeanFactory getAutowireCapableBeanFactory() throws IllegalStateException;
}ApplicationContext的实质功能都是继承于以下6个实体:
MessageSource: 用于国际化的接口，可以将其理解为公司的翻译。用户可以通过bean配置自定义MessageSource–要求name为“messageSource”，spring会在容器refresh时自动探测并且初始化它。
ApplicationEventPublisher: 用于发布应用事件，例如ContextRefreshed，stopped, started等。它就像是企业邮箱，通过它可以接收到公司的事件通知。用户通过配置ApplicationListener类型的bean即可订阅这类事件，spring通过getBeansOfType取得所有的listener，并依次通知。
ResourcePatternResolver: 对ResourceLoader的扩展，后者只支持对具体路径资源的加载，而前者则支持对某pattern路径资源的加载，默认是ant风格的模式。Resource是特指配置文件，或者class路径(里的扫描路径)。我们可以将它理解为打单的机器，将各个地方发过来的单子打出来。
ListableBeanFactory和HierachicalBeanFactory: 自然的context也是个工厂，context里持有的依然是DefaultListableBeanFactory，通过它完成工厂的相应行为。介绍下这两个工厂，前者主要用于取得批量bean，比如getBeansOfType；后一个工厂则主要体现层级概念，但是context的parentFactory也是一个context，这是因为context具有beanFactory的所有特征。
EnviromentCapable: 则类似是公司的行政部门，负责办公场所等设施维护。它关联着Enviroment。Enviroment也类似context是个包装类，虽然继承了PropertyResolver，但在实现类里是委托给ConfigurablePropertyResolver处理的。Enviroment代表应用环境，比如测试环境还是生产环境又或者开发环境。
用户可以通过或者@Profile指定某个配置的profile。然后通过activeProfile指定应用环境，从而会enable相应profile的beans
activeProfile可以通过5种方式指定：
1）. servlet config init param，这种方式只适用于spring mvc的dispatcherServlet配置上
2）. servlet context init param
3）. system property
4）. system env。以上四种方式设置的key均为spring.profiles.active
5.） @ActiveProfile，这种方式只适用于junit单元测试
Context通过继承获得了工厂，事件发布，环境定义，资源加载以及国际化的能力。
context静态结构
这一节我只抽一些比较重要的接口的源码讲述，主要还是注重概念和原理，后面会专门出一篇讲context的动态处理过程，那里面会对具体实现类做详述。这一篇泽主要是建立对context静态类结构的理解。
下图是web application context的类图，可以和构成部件的结构图结合着看，上面的图每个实体都是spring context的一个接口。
常见的WebApplicationContext实现主要有两个，分别是XmlWebApplicationContext和AnnotationConfigWebApplicationContext。他们共同的父类为AbstractRefreshableWebApplicationContext，我们从它出发，看一下context的类结构。
LifeCycle和Closeable代表着容器的整个生命周期，被ConfigurableApplicationContext继承，使继承该接口的context具有生命周期的特征。
public interface Lifecycle {
void start();
void stop();
boolean isRunning();
}
用户可以配置Lifecycle类型bean，在context start以及stop时也会相应的启动LifeCycle bean的start或者stop。对于允许autoStartup的SmartLifecycle，context refresh的过程中会自动启动。
ConfigurableApplicationContext继承了生命周期，代表一个可以修改相关属性行为的context，上一节提到的Enviroment和ApplicationListener等等都可以通过它设置。同时整个context的核心refresh方法也是定义在他里面，所以所有的context都继承了它。
public interface ConfigurableApplicationContext extends ApplicationContext, Lifecycle, Closeable {
void setId(String id);
void setParent(ApplicationContext parent);
ConfigurableEnvironment getEnvironment();
void setEnvironment(ConfigurableEnvironment environment);
//添加bean后处理器，[beans架构](http://blog.csdn.net/szwandcj/article/details/50688616)架构里详细讲过后处理器
void addBeanFactoryPostProcessor(BeanFactoryPostProcessor beanFactoryPostProcessor);
void addApplicationListener(ApplicationListener<?> listener);
//context核心方法，refresh是整个容器构建的过程
void refresh() throws BeansException, IllegalStateException;
//注册jdk进程退出时的hook
void registerShutdownHook();
void close();
boolean isActive();
ConfigurableListableBeanFactory getBeanFactory() throws IllegalStateException;
}实现这个接口的AbstractApplicationContext很自然的也承担了context的绝大部分职能，上一节提过的context的六个方面的功能就几乎都是由它实现，除BeanFactory以外，其它的4个实体都是聚合在这个类里。而DefaultListableBeanFactory–那个最著名的BeanFactory则是由它的子类AbstractRefreshableApplicationContext生成，它自己通过模板方法使用。
AbstractRefreshableApplicationContext定义了loadBeanDefinitions模板方法，由具体的实现提供。它创建bean factory并load配置文件。beans配置文件load过程参考这里
AbstractRefreshableConfigApplicationContext主要用于设置资源的路径。几乎所有的ApplicationContext都会继承这个类，除非不需要读取配置资源。
AbstractRefreshableWebApplicationContext主要针对web的一些特性提供一些context属性行为设置能力，例如覆盖默认的enviroment（默认的由AbstractApplicationContext提供），生成StandardServletEnviroment，又例如覆盖ResourcePatternResolver以及对BeanFactory的后处理等。
ConfigurableWebApplicationContext则是web application context的通用接口，为了支持spring-mvc和spring-web定义了一些set方法，例如设置configLocations（ConfigurableApplicationContext接口并不支持setConfigLocation，因为这个接口是跟着ClassPathXmlApplicationContext一起发布的，而web和mvc是后来加上的功能）和nameSpace等。可以把它看成是专门支持web和mvc的一个接口（web和mvc中生成context是通过class.newInstance的无参构造，所以无法将这些信息作为参数传入，必须显示提供set方法以设置属性）
public interface ConfigurableWebApplicationContext extends WebApplicationContext, ConfigurableApplicationContext {
void setServletContext(ServletContext servletContext);
void setServletConfig(ServletConfig servletConfig);
ServletConfig getServletConfig();
void setNamespace(String namespace);
String getNamespace();
void setConfigLocation(String configLocation);
void setConfigLocations(String... configLocations);
String[] getConfigLocations();
}Enviroment实现
再具体说下Enviroment的实现，还是挺有意思的。下图是enviroment的序列图
主要说下MutablePropertySources和PropertySource。
最终属性值是通过PropertySource取得，它有多种实现，分别代表一种来源的属性。第二节提到的4种来源则分别对应着ServletConfigPropertySource，ServletContextPropertySource，MapPropertySource和SystemEnvironmentPropertySource。
MutablePropertySources里持有一个property的list，对它迭代直到从一个PropertySource里取出对应key的值就停止，从这可以就看出spring.profiles.active是有先后优先级的。
有兴趣的可以看下源码，会稍微有些繁琐。有一点需要注意：spring web和mvc模块会在refresh applicationContext之前调用相应enviroment#initPropertySources生成ServletConfigPropertySource和ServletContextPropertySource。相应的MapPropertySource和SystemEnvironmentPropertySource则是默认生成的。所以如果不是web项目，就只能通过配置system properties或者env指定activeProfile。
