Java 1.5(Tiger) 个人认为最为激动人心的两个特性是泛型与注解(Java Versions, Features and History)。泛型自然是不必说了，注解对 Java 世界的改变比泛型伟大的多(现在框架的注解配置)，在 Java 1.5 之前我们只能在 Javadoc 注释中做文章，于是只能用 XDoclet 那样不伦不类的东西。Java 的注解发展到现在几乎可以使用在书写代码时的任何地方，见 java.lang.annotation.ElementType 中的类型，囊括了 TYPE, FIELD, METHOD, PARAMETER, CONSTRUCTOR, LOCAL_VARIABLE, ANNOTATION_TYPE, PACKAGE, TYPE_PARAMETER(since 1.8), TYPE_USE(since 1.8)。

Java 1.5 基本确定了注解的基本框架，包括元注解(meta-annotation); 直到 Java 8 又扩展了注解的使用范围，列举如下：

创建类实例

new@Interned MyObject();

类型映射

myString = (@NonNull String) str;

implements 语句中

class UnmodifiableList<T> implements@Readonly List<@Readonly T> { ... }

throw exception声明

void monitorTemperature() throws@Critical TemperatureException { ... }

解析前面 ElementType Java 8 增加的 TYPE_PARAMETER和 TYPE_USE 注解使用新场合。ElementType.TYPE_PARAMETER 表示该注解能写在类型变量的声明语句中。ElementType.TYPE_USE 表示该注解能写在使用类型的任何语句中(如: 声明语句、泛型和强制转换语句中的类型) Read More

在 Spring 中应用 ServiceLocator 方式来获取 Spring Bean 的介绍参考了那么多，其实还是数官方的 ServiceLocatorFactoryBean JavaDoc 文档最言简意该了。Spring 的 ServiceLocator 仿佛用处不大，说到底就是类似于下方找寻某个 Spring Bean 一样：

ApplicationContext context = ...; Service service = context.getBean(ServiceImpl.class); Service service = context.getBean("myService");

只是有了 ServiceLocatorFactoryBean(它本质上就是一个 FactoryBean) 后我们不需要直接与 ApplicationContext 打交道，且多个的 Spring Bean 可以从相关的一个 FactoryBean 获得。下面用两个例子来演示(代码中刨去了 package 和 import 部分的代码)

一：实现类只有一个 Spring Bean 时

接口类 Parser(我们要定位就是它的实现类) Read More

许久没记录笔记了，这回来重新熟悉一下 Spring 中 FactoryBean 的使用，顾名思义，它是用来获得相应 Bean 的工厂的。它与另一个 Spring 中的接口 BeanFactory 的作用不一样的，不能多说了。FactoryBean 和 BeanFactory 都是在 org.springframework.beans.factory 包中，谁能一看类名搞清楚它们的差别？

1. FactoryBean: 用于创建某个特定的 Spring bean 的工厂类
2. BeanFactory: Spring 上下文的最顶层接口，如 ApplicationContext 就继承了该接口，它可称之为所有 Spring bean 的工厂

这儿说的是第一个 FactoryBean, 它的接口声明是

1public interface FactoryBean<T> {
2    T getObject() throws Exception;
3    Class<?> getObjectType();
4    boolean isSingleton();
5}

它最终的效果是，Spring 容器中注册一个名称为 abcFactoryBean 的 AbcFactoryBean 实例，通后名称 abcFactoryBean 获得的实际上是相应 AbcFactoryBean.getObject() 返回的对象，类型为 getObjectType(), isSingleton() 是否是单例。 Read More

本文记录 SpringBoot 与 Logback 是如何工作的，即观察 SpringBoot 中 Logback  是怎么一步一步初始化的。用以测试的 SpringBoot 版本是 1.5.16, 而非最新的 SpringBoot 2。关于 SpringBoot 日志的官方文档在 Logging, 但不太详细或透彻。本文也不承诺说就理解得更有深度，只是为官方文档提供更多方面的参考。

SpringBoot 默认使用 Slf4J + Logback 来记录日志，对于一个基本的依赖于

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
</dependency>

的 Spring Boot 项目，上面组件依赖了 spring-boot-starter-logging 组件，而该组件又引入了以下几个依赖

1. logback-classic:   依赖了 Slf4J
2. jcl-over-slf4j
3. jul-to-slf4j
4. log4j-over-slf4j

相当于把其他的日志框架全桥接到了 Slf4J + Logback 上去了。 Read More

我们的问题

GET /users/{userId}     UserController.getUserInfo                                    //默认
GET /users/{userId}     UserController.getUserInfo                                   //当有 ?source=file 时
GET /users/{userId}     CloudUserController.getUserInfoFromCloud       //当有 ?source=cloud 时

项目结构布局

Spring 相关代码分析

1@SpringBootApplication
2@ComponentScan(basePackages = "cc.unmi")
3public class DemoApplication {
4    public static void main(String[] args) {
5        SpringApplication.run(DemoApplication.class, args);
6    }
7}

用过  Spring 的 @EnableScheduling 的都知道，我们用三种形式来部署计划任务，即 @Scheduled 注解的 fixedRate(fixedRateString), fixedDelay(fixedDelayString), 以及 cron. cron 不在这里讨论的范畴。我们着重在如何理解 fixedRate 和 fixedDelay 的区别。

在 Spring 的  Scheduled 注解的 JavaDoc 对此的解释很简单

public abstract long fixedRate
Execute the annotated method with a fixed period in milliseconds between invocations.

public abstract long fixedDelay
Execute the annotated method with a fixed period in milliseconds between the end of the last invocation and the start of the next.

只是说是 fixedRate 任务两次执行时间间隔是任务的开始点，而 fixedDelay 的间隔是前次任务的结束与下次任务的开始。

大致用示意字符串来表示如下(每个 T1, 或 T2 代表任务执行秒数(每次任务执行时间不定)，假定 fixedRate 或  fixedDelay 的值是 5 秒，用 W 表示等待的数)

fixedRate:    T1.T1WWWT2.T2.T2WW.T3.T3.T3.T3.T3.T4.T4.T4.T4.T4.T4.T4T5T5WWWT6.T6........

fixedDelay:  T1.T1.WWWWW.T2.T2.T2WWWWW.T3.T3.T3.T3.T3.WWWWW.T4.T4.T4.T4.T4.T4.T4.WWWWWT6.T6......

一般来说能理解到上面两个场景已经差不多了，相比而言 fixedDelay 简单些，盯着上一次任务的屁股就行。 Read More

Spring 定时任务实例

 1<parent>
 2    <groupId>org.springframework.boot</groupId>
 3    <artifactId>spring-boot-starter-parent</artifactId>
 4    <version>1.5.3.RELEASE</version>
 5</parent>
 6<dependencies>
 7    <dependency>
 8        <groupId>org.springframework.boot</groupId>
 9        <artifactId>spring-boot-starter</artifactId>
10    </dependency>
11</dependencies>