直接上文档吧，很方便！

    1. Indicates that a class declares one or more @Bean methods and may be processed by the Spring container to generate bean definitions and service requests for those beans at runtime, for example:
    2.    @Configuration
    3.    public class AppConfig {
    5.        @Bean
    6.        public MyBean myBean() {
    7.            // instantiate, configure and return bean ...
    8.        }
    9.    }
    10. Bootstrapping @Configuration classes
    11. Via AnnotationConfigApplicationContext
    12. @Configuration classes are typically bootstrapped using either AnnotationConfigApplicationContext or its web-capable variant, AnnotationConfigWebApplicationContext. A simple example with the former follows:
    13.    AnnotationConfigApplicationContext ctx = new AnnotationConfigApplicationContext();
    14.    ctx.register(AppConfig.class);
    15.    ctx.refresh();
    16.    MyBean myBean = ctx.getBean(MyBean.class);
    17.    // use myBean ...
    19. See the AnnotationConfigApplicationContext javadocs for further details, and see AnnotationConfigWebApplicationContext for web configuration instructions in a Servlet container.
    20. Via Spring <beans> XML
    21. As an alternative to registering @Configuration classes directly against an AnnotationConfigApplicationContext, @Configuration classes may be declared as normal <bean> definitions within Spring XML files:
    22.    <beans>
    23.       <context:annotation-config/>
    24.       <bean class="com.acme.AppConfig"/>
    25.    </beans>
    27. In the example above, <context:annotation-config/> is required in order to enable ConfigurationClassPostProcessor and other annotation-related post processors that facilitate handling @Configuration classes.
    28. Via component scanning
    29. @Configuration is meta-annotated with @Component, therefore @Configuration classes are candidates for component scanning (typically using Spring XML's <context:component-scan/> element) and therefore may also take advantage of @Autowired/@Inject like any regular @Component. In particular, if a single constructor is present autowiring semantics will be applied transparently for that constructor:
    30.    @Configuration
    31.    public class AppConfig {
    33.        private final SomeBean someBean;
    35.        public AppConfig(SomeBean someBean) {
    36.            this.someBean = someBean;
    37.        }
    39.        // @Bean definition using "SomeBean"
    41.    }
    42. @Configuration classes may not only be bootstrapped using component scanning, but may also themselves configure component scanning using the @ComponentScan annotation:
    43.    @Configuration
    44.    @ComponentScan("com.acme.app.services")
    45.    public class AppConfig {
    46.        // various @Bean definitions ...
    47.    }
    48. See the @ComponentScan javadocs for details.
    49. Working with externalized values
    50. Using the Environment API
    51. Externalized values may be looked up by injecting the Spring org.springframework.core.env.Environment into a @Configuration class — for example, using the @Autowired annotation:
    52.    @Configuration
    53.    public class AppConfig {
    55.        @Autowired Environment env;
    57.        @Bean
    58.        public MyBean myBean() {
    59.            MyBean myBean = new MyBean();
    60.            myBean.setName(env.getProperty("bean.name"));
    61.            return myBean;
    62.        }
    63.    }
    64. Properties resolved through the Environment reside in one or more "property source" objects, and @Configuration classes may contribute property sources to the Environment object using the @PropertySource annotation:
    65.    @Configuration
    66.    @PropertySource("classpath:/com/acme/app.properties")
    67.    public class AppConfig {
    69.        @Inject Environment env;
    71.        @Bean
    72.        public MyBean myBean() {
    73.            return new MyBean(env.getProperty("bean.name"));
    74.        }
    75.    }
    76. See the Environment and @PropertySource javadocs for further details.
    77. Using the @Value annotation
    78. Externalized values may be injected into @Configuration classes using the @Value annotation:
    79.    @Configuration
    80.    @PropertySource("classpath:/com/acme/app.properties")
    81.    public class AppConfig {
    83.        @Value("${bean.name}") String beanName;
    85.        @Bean
    86.        public MyBean myBean() {
    87.            return new MyBean(beanName);
    88.        }
    89.    }
    90. This approach is often used in conjunction with Spring's PropertySourcesPlaceholderConfigurer that can be enabled automatically in XML configuration via <context:property-placeholder/> or explicitly in a @Configuration class via a dedicated static @Bean method (see "a note on BeanFactoryPostProcessor-returning @Bean methods" of @Bean's javadocs for details). Note, however, that explicit registration of a PropertySourcesPlaceholderConfigurer via a static @Bean method is typically only required if you need to customize configuration such as the placeholder syntax, etc. Specifically, if no bean post-processor (such as a PropertySourcesPlaceholderConfigurer) has registered an embedded value resolver for the ApplicationContext, Spring will register a default embedded value resolver which resolves placeholders against property sources registered in the Environment. See the section below on composing @Configuration classes with Spring XML using @ImportResource; see the @Value javadocs; and see the @Bean javadocs for details on working with BeanFactoryPostProcessor types such as PropertySourcesPlaceholderConfigurer.
    91. Composing @Configuration classes
    92. With the @Import annotation
    93. @Configuration classes may be composed using the @Import annotation, similar to the way that <import> works in Spring XML. Because @Configuration objects are managed as Spring beans within the container, imported configurations may be injected — for example, via constructor injection:
    94.    @Configuration
    95.    public class DatabaseConfig {
    97.        @Bean
    98.        public DataSource dataSource() {
    99.            // instantiate, configure and return DataSource
    100.        }
    101.    }
    103.    @Configuration
    104.    @Import(DatabaseConfig.class)
    105.    public class AppConfig {
    107.        private final DatabaseConfig dataConfig;
    109.        public AppConfig(DatabaseConfig dataConfig) {
    110.            this.dataConfig = dataConfig;
    111.        }
    113.        @Bean
    114.        public MyBean myBean() {
    115.            // reference the dataSource() bean method
    116.            return new MyBean(dataConfig.dataSource());
    117.        }
    118.    }
    119. Now both AppConfig and the imported DatabaseConfig can be bootstrapped by registering only AppConfig against the Spring context:
    120.    new AnnotationConfigApplicationContext(AppConfig.class);
    121. With the @Profile annotation
    122. @Configuration classes may be marked with the @Profile annotation to indicate they should be processed only if a given profile or profiles are active:
    123.    @Profile("development")
    124.    @Configuration
    125.    public class EmbeddedDatabaseConfig {
    127.        @Bean
    128.        public DataSource dataSource() {
    129.            // instantiate, configure and return embedded DataSource
    130.        }
    131.    }
    133.    @Profile("production")
    134.    @Configuration
    135.    public class ProductionDatabaseConfig {
    137.        @Bean
    138.        public DataSource dataSource() {
    139.            // instantiate, configure and return production DataSource
    140.        }
    141.    }
    142. Alternatively, you may also declare profile conditions at the @Bean method level — for example, for alternative bean variants within the same configuration class:
    143.    @Configuration
    144.    public class ProfileDatabaseConfig {
    146.        @Bean("dataSource")
    147.        @Profile("development")
    148.        public DataSource embeddedDatabase() { ... }
    150.        @Bean("dataSource")
    151.        @Profile("production")
    152.        public DataSource productionDatabase() { ... }
    153.    }
    154. See the @Profile and org.springframework.core.env.Environment javadocs for further details.
    155. With Spring XML using the @ImportResource annotation
    156. As mentioned above, @Configuration classes may be declared as regular Spring <bean> definitions within Spring XML files. It is also possible to import Spring XML configuration files into @Configuration classes using the @ImportResource annotation. Bean definitions imported from XML can be injected — for example, using the @Inject annotation:
    157.    @Configuration
    158.    @ImportResource("classpath:/com/acme/database-config.xml")
    159.    public class AppConfig {
    161.        @Inject DataSource dataSource; // from XML
    163.        @Bean
    164.        public MyBean myBean() {
    165.            // inject the XML-defined dataSource bean
    166.            return new MyBean(this.dataSource);
    167.        }
    168.    }
    169. With nested @Configuration classes
    170. @Configuration classes may be nested within one another as follows:
    171.    @Configuration
    172.    public class AppConfig {
    174.        @Inject DataSource dataSource;
    176.        @Bean
    177.        public MyBean myBean() {
    178.            return new MyBean(dataSource);
    179.        }
    181.        @Configuration
    182.        static class DatabaseConfig {
    183.            @Bean
    184.            DataSource dataSource() {
    185.                return new EmbeddedDatabaseBuilder().build();
    186.            }
    187.        }
    188.    }
    189. When bootstrapping such an arrangement, only AppConfig need be registered against the application context. By virtue of being a nested @Configuration class, DatabaseConfig will be registered automatically. This avoids the need to use an @Import annotation when the relationship between AppConfig and DatabaseConfig is already implicitly clear.
    190. Note also that nested @Configuration classes can be used to good effect with the @Profile annotation to provide two options of the same bean to the enclosing @Configuration class.
    191. Configuring lazy initialization
    192. By default, @Bean methods will be eagerly instantiated at container bootstrap time. To avoid this, @Configuration may be used in conjunction with the @Lazy annotation to indicate that all @Bean methods declared within the class are by default lazily initialized. Note that @Lazy may be used on individual @Bean methods as well.
    193. Testing support for @Configuration classes
    194. The Spring TestContext framework available in the spring-test module provides the @ContextConfiguration annotation which can accept an array of component class references — typically @Configuration or @Component classes.
    195.    @RunWith(SpringRunner.class)
    196.    @ContextConfiguration(classes = {AppConfig.class, DatabaseConfig.class})
    197.    public class MyTests {
    199.        @Autowired MyBean myBean;
    201.        @Autowired DataSource dataSource;
    203.        @Test
    204.        public void test() {
    205.            // assertions against myBean ...
    206.        }
    207.    }
    208. See the TestContext framework  reference documentation for details.
    209. Enabling built-in Spring features using @Enable annotations
    210. Spring features such as asynchronous method execution, scheduled task execution, annotation driven transaction management, and even Spring MVC can be enabled and configured from @Configuration classes using their respective "@Enable" annotations. See @EnableAsync, @EnableScheduling, @EnableTransactionManagement, @EnableAspectJAutoProxy, and @EnableWebMvc for details.
    211. Constraints when authoring @Configuration classes
    212. Configuration classes must be provided as classes (i.e. not as instances returned from factory methods), allowing for runtime enhancements through a generated subclass.
    213. Configuration classes must be non-final (allowing for subclasses at runtime), unless the proxyBeanMethods flag is set to false in which case no runtime-generated subclass is necessary.
    214. Configuration classes must be non-local (i.e. may not be declared within a method).
    215. Any nested configuration classes must be declared as static.
    216. @Bean methods may not in turn create further configuration classes (any such instances will be treated as regular beans, with their configuration annotations remaining undetected).
    217. Since:
    218. 3.0
    219. See Also:
    220. Bean, Profile, Import, ImportResource, ComponentScan, Lazy, PropertySource, AnnotationConfigApplicationContext, ConfigurationClassPostProcessor, org.springframework.core.env.Environment, org.springframework.test.context.ContextConfiguration
    223. @Target(ElementType.TYPE)
    224. @Retention(RetentionPolicy.RUNTIME)
    225. @Documented
    226. @Component
    227. public @interface Configuration {
    229.     /**
    230.      * Explicitly specify the name of the Spring bean definition associated with the
    231.      * {@code @Configuration} class. If left unspecified (the common case), a bean
    232.      * name will be automatically generated.
    233.      * <p>The custom name applies only if the {@code @Configuration} class is picked
    234.      * up via component scanning or supplied directly to an
    235.      * {@link AnnotationConfigApplicationContext}. If the {@code @Configuration} class
    236.      * is registered as a traditional XML bean definition, the name/id of the bean
    237.      * element will take precedence.
    238.      * @return the explicit component name, if any (or empty String otherwise)
    239.      * @see AnnotationBeanNameGenerator
    240.      */
    241.     @AliasFor(annotation = Component.class)
    242.     String value() default "";
    244.     /**
    245.      * Specify whether {@code @Bean} methods should get proxied in order to enforce
    246.      * bean lifecycle behavior, e.g. to return shared singleton bean instances even
    247.      * in case of direct {@code @Bean} method calls in user code. This feature
    248.      * requires method interception, implemented through a runtime-generated CGLIB
    249.      * subclass which comes with limitations such as the configuration class and
    250.      * its methods not being allowed to declare {@code final}.
    251.      * <p>The default is {@code true}, allowing for 'inter-bean references' via direct
    252.      * method calls within the configuration class as well as for external calls to
    253.      * this configuration's {@code @Bean} methods, e.g. from another configuration class.
    254.      * If this is not needed since each of this particular configuration's {@code @Bean}
    255.      * methods is self-contained and designed as a plain factory method for container use,
    256.      * switch this flag to {@code false} in order to avoid CGLIB subclass processing.
    257.      * <p>Turning off bean method interception effectively processes {@code @Bean}
    258.      * methods individually like when declared on non-{@code @Configuration} classes,
    259.      * a.k.a. "@Bean Lite Mode" (see {@link Bean @Bean's javadoc}). It is therefore
    260.      * behaviorally equivalent to removing the {@code @Configuration} stereotype.
    261.      * @since 5.2
    262.      */
    263.     boolean proxyBeanMethods() default true;
    265. }

    proxyBeanMethods表示是否为当前Configuration类生成一个CGLib代理，默认为true, 表示每次调用内部的@Bean方法时，直接返回容器里的单例bean,否则每次调用都会生成新的Bean实例。

    举个例子：

    1. @Configuration(proxyBeanMethods = false)
    2. @ConditionalOnProperty(prefix = "demo", name = "auto", havingValue = "true", matchIfMissing = false)
    3. public class DemoAutoConfiguration {
    5.     public DemoAutoConfiguration() {
    6.         System.out.println("##DemoAutoConfiguration##");
    7.     }
    10.     @Bean(name = "addr1")
    11.     public AddressService addrService() {
    12.         return new AddressService();
    13.     }
    14. }
    1.     @Autowired
    2.     private DemoAutoConfiguration demoAutoConfiguration;
    4.     @Autowired
    5.     @Qualifier("addr1")
    6.     private DemoAutoConfiguration.AddressService addressService1;
    8.     public void run(ApplicationArguments args) throws Exception {
    9.         DemoAutoConfiguration.AddressService addressService = demoAutoConfiguration.addrService();
    10.         System.out.println(addressService == addressService1);
    11.     }

    如果proxyBeanMethods=false, 则demoAutoConfiguration.addrService()方法返回新的对象，与addressService1不一致，如果proxyBeanMethods=true,则每次调用demoAutoConfiguration.addrService()返回的对象为容器里的bean,与addressService1一致。