Guice框架

Guice是Google开发的一个轻量级的DI框架，Guice在2008年获得了软件界的奥斯卡--Jolt奖，核心的功能就是依赖反转。Guice的依赖反转比较简单，在Guice中有一个Module的接口，实现Module接口在configure方法中进行bind-to的操作，就完成了一个类型对应实现的绑定。Druid中大量的使用了Guice，要搞清楚代码究竟干了什么，首先先了解下Druid中是如何使用Guice的。

常量绑定

在Guice中可以把一个值与一个常量绑定。

public class A {
    ...
    @Inject
    @Named("aConstant")
    private String aConstant;
}

上面的代码中有一个字段是通过注入来设置值的，对于种类型的bind是这样的：

public class AModule implements Module{
    public void configure(Binder binder){
        binder.bindConstant().annotatedWith(Names.named("aConstant")).to("aConstant")
    }
}

上述代码的意思是绑定一个用Named注解修饰的常量，且注解的值是aConstant注入值为aConstant。

直连绑定

接口绑定就是最基础的常用的绑定，如果对SpringMVC比较熟悉的话接口绑定应该是最常用的绑定的方式了。举个简单的例子，我们想对接口TestInterface绑定一个实现可以使用直接绑定

binder.bind(TestInterface.class).to(TestInterfaceImpl.class).in(Scopes.SINGLETON);

绑定注解

有的时候对于同一个接口可能有多个实现，这个时候可以用一个额外的注解来进行限定。比如对于上个例子的TestInterface有一个其他的实现，这个时候可以创建一个绑定注解：

@BindingAnnotation
@Retention(RUNTIME)
@Target({FIELD, METHOD, TYPE})
public @interface Test {
}

然后我们在Module中就可以这样绑定：

binder.bind(TestInterface.class)
                .annotatedWith(Test.class)
                .to(TestAnnotationImpl.class)
                .in(Scopes.SINGLETON);

获取有两种常见的方式，第一种是使用Test注解：

    @Inject
    public C(B b, @Test TestInterface testInterface) {
        this.testInterface = testInterface;
        this.b = b;
    }

另一种方式是通过Key去获取：

TestInterface annotationInterface = injector.getInstance(Key.get(TestInterface.class, Test.class));

Provides注解

当你需要一定的代码来创建一个对象的时候可以使用@Providers注解，注解修饰一个方法，这个方法必须放到Module中，同时可以结合上面绑定注解一起使用。对于上个如果使用Providers注解的话首先把绑定的代码去掉就是binder.bind那里，其次在任意一个Module中provide一个对象：

    @Test
    @Provides
    @Singleton
    public TestInterface provideTest(){
        return new TestProvidersImpl();
    }

获取的方式是不变的。

隐式绑定

Druid中使用的隐式绑定和文档中的不太一样，看起来Druid中的隐式绑定更多的是为了注入，Druid中隐式绑定是直接写一个类，然后在bind的时候并没有声明target。这样做的好处是有些东西并不需要写接口，但是你可能要注入。

public class A {

    private B b;

    @Inject
    public A(B b) {
        this.b = b;
    }

    public void doBTest(){
        b.doB();
    }
}

绑定的时候：

binder.bind(A.class).in(Scopes.SINGLETON);

Provider接口

当@Providers的方法开始变得复杂了，你想把它移动到自己的类中，那么可以通过实现Provider接口来达到目的。如下：

public class TestProvider implements Provider<TestInterface> {

    @Override
    public TestInterface get() {
        return new TestInterface() {
            public void test() {
                System.out.println("provider test");
            }
        };
    }

}

绑定的部分：

binder.bind(TestInterface.class).toProvider(TestProvider.class).in(Scopes.SINGLETON);

MapBinder

MapBinder顾名思义就是注入一个实现的Map

MapBinder<String, CheckHandler> mapBinder = MapBinder.newMapBinder(binder(), String.class, CheckHandler.class);
mapBinder.addBinding("Hello").to(InstalledCheckHandler.class);

JsonConfigProvider

Druid的代码中大量的使用了JsonConfigProvider，这个类主要是用于读取配置，实际上它干的事儿跟Springboot中@Configuration很像。它就是将配置文件中一些固定前缀的配置项映射到一个配置类中。如果没有使用过Springboot的话，对于配置类还是比较陌生的，配置类其实就是在用Java去写配置，比如一个Server，你可能需要一个ServerConfig类，这个类中有一些字段都是Server的配置，如host，port等等。当你需要使用ServerConfig的时候只需要调用ServerConfig中相应的方法就可以。看一下Druid中例子：

JsonConfigProvider.bind(binder, "druid.indexer.task", TaskConfig.class);

这样调用的结果是将druid.indexer.task为前缀的property项目都映射到TaskConfig的同名字段中。比如druid.indexer.task.baseDir会映射到TaskConfig的baseDir字段，前提是类中需要一些Jackson的注解的设置。
这个类注入了一个Properties对象，这个对象包含配置文件中的配置，同时还会注入一个JsonConfigurator。JsonConfigProvider是一个实现了Provider<Supplier<T>>接口的泛型类。看一下bind方法：

public static <T> void bind(
        Binder binder,
        String propertyBase,
        Class<T> clazz,
        Key<T> instanceKey,
        Key<Supplier<T>> supplierKey) {
    binder.bind(supplierKey).toProvider((Provider) of(propertyBase, clazz)).in(LazySingleton.class);
    binder.bind(instanceKey).toProvider(new SupplierProvider<T>(supplierKey));
    }

这个bind方法是把Supplier<T>绑定一个Provider，这个Provider就是这个JsonProvider。它的get方法：

    public Supplier<T> get() {
        if (retVal != null) {
            return retVal;
        }

        try {
            final T config = configurator.configurate(props, propertyBase, classToProvide);
            retVal = Suppliers.ofInstance(config);
        } catch (RuntimeException e) {
            retVal = Suppliers.ofInstance(null);
            throw e;
        }
        return retVal;
    }

可以看出是通过JsonConfigurator生成一个配置类的实例，然后包一个Supplier返回回来。获取实例的部分就是把配置文件放到一个Map里面，然后结合类中Jackson注解通过Jackson框架来进行赋值处理。
上面的bind方法除了把Supplier<T>绑定了一个Provider之外，又把T绑定了一个SupplierProvider，看下SupplierProvider的代码：

public class SupplierProvider<T> implements Provider<T> {
    private final Key<Supplier<T>> supplierKey;

    private Provider<Supplier<T>> supplierProvider;

    public SupplierProvider(Key<Supplier<T>> supplierKey) {
        this.supplierKey = supplierKey;
    }

    @Inject
    public void configure(Injector injector) {
        this.supplierProvider = injector.getProvider(supplierKey);
    }

    @Override
    public T get() {
        return supplierProvider.get().get();
    }
}

构造器中传入的是一个supplierKey，然后注入的时候通过SupplierKey拿到SupplierPovider，然后get方法是supplierProvider.get().get()

PolyBind

PolyBind主要是利用MapBinder来创建一个可选的Binding，比如Overlord的运行模式有两个，一个是本地，一个是远程。通过配置文件来指定本地模式运行或者远程模式运行，这个时候就用PolyBind来实现这个功能。首先TaskRunner是通过TaskRunnerFactory生产出来的，所以两种不同的实现对应两种不同的Factory。所以对于TaskRunner就变成了根据配置文件不同的属性来选择不同的Factory。

PolyBind.createChoice(
        binder,
        "druid.indexer.runner.type",
        Key.get(TaskRunnerFactory.class),
        Key.get(ForkingTaskRunnerFactory.class));

看一下createChoice的实现：

    public static <T> ScopedBindingBuilder createChoiceWithDefault(
            Binder binder,
            String property,
            Key<T> interfaceKey,
            Key<? extends T> defaultKey,
            String defaultPropertyValue) {
        return binder.bind(interfaceKey).toProvider(new ConfiggedProvider<T>(interfaceKey, property, defaultKey, defaultPropertyValue));
    }

这个ConfiggedProvider是干什么的呢？

    static class ConfiggedProvider<T> implements Provider<T> {
        private final Key<T> key;
        private final String property;
        private final Key<? extends T> defaultKey;
        private final String defaultPropertyValue;

        private Injector injector;
        private Properties props;

        ConfiggedProvider(
                Key<T> key,
                String property,
                Key<? extends T> defaultKey,
                String defaultPropertyValue
        ) {
            this.key = key;
            this.property = property;
            this.defaultKey = defaultKey;
            this.defaultPropertyValue = defaultPropertyValue;
        }

        @Inject
        void configure(Injector injector, Properties props) {
            this.injector = injector;
            this.props = props;
        }

        @Override
        @SuppressWarnings("unchecked")
        public T get() {
            final ParameterizedType mapType = Types.mapOf(
                    String.class, Types.newParameterizedType(Provider.class, key.getTypeLiteral().getType())
            );

            final Map<String, Provider<T>> implsMap;
            if (key.getAnnotation() != null) {
                implsMap = (Map<String, Provider<T>>) injector.getInstance(Key.get(mapType, key.getAnnotation()));
            } else if (key.getAnnotationType() != null) {
                implsMap = (Map<String, Provider<T>>) injector.getInstance(Key.get(mapType, key.getAnnotation()));
            } else {
                implsMap = (Map<String, Provider<T>>) injector.getInstance(Key.get(mapType));
            }

            String implName = props.getProperty(property);
            if (implName == null) {
                implName = defaultPropertyValue;
            }
            final Provider<T> provider = implsMap.get(implName);

            if (provider == null) {
                if (defaultKey == null) {
                    throw new ProvisionException(
                            String.format("Unknown provider[%s] of %s, known options[%s]", implName, key, implsMap.keySet())
                    );
                }
                return injector.getInstance(defaultKey);
            }

            return provider.get();
        }
    }

可以看到，这个ConfiggedProvider首先注入了一个properties，然后再get方法中，首先先拿到接口的MapBind，然后用出入的property作为key去properties中取获取implName，如果implName是null则用默认的，这里默认的也可能为null。如果从BindMap中没有取到对应的实现，则通过defaultKey直接获取对应的实例，然后返回。如果获取到对应的Provider，则调用Provider的get方法。
CreateChoiceWithDefault之后，这个接口就对应了一个ConfiggedProvider的实现，如果想继续添加选项可以配合使用PolyBind.optionBinder和addBinding来处理。

final MapBinder<String, TaskRunnerFactory> biddy = PolyBind.optionBinder(
        binder,
        Key.get(TaskRunnerFactory.class)
);
biddy.addBinding("local").to(ForkingTaskRunnerFactory.class);

这个就是很简单了，就是创建一个对应接口的MapBind，然后通过addBind向Map里面添加值。总结起来就是这个接口对应一个Provider，Provider的get方法会去找基于这个接口的MapBind，然后从MapBind中找Prop中指定的实现，如果没有就用默认的实现。MapBind可以通过OptionBinder来创建，通过addBInder方法添加Key-Impl。

LifeCycle

LifeCycle就是类似于Spring的postadd和predestroy的东西，想想当年Twell没用Spring也搞过类似的东西。注册到LifeCycle里的东西必须有start和close方法或者有@LifeCycleStart注解或者@LifeCycleStop注解修饰的方法。LifeCycle中有State的概念，分为Normal和Last两个值，start过程中先执行Normal的，都是Normal的按照加入的顺序去执行，然后执行Last的，在关闭的过程中就按照完全相反的顺序去执行。

Jetty+Jersey+guice

Druid的服务使用的是一个内置的Jetty，rest接口使用的是Jersey。至少看起来是这一个样子的。Druid不同的节点会有不同的Server配置。这个是通过实现JettyServerInitializer接口实现的，什么时候调用的initialize方法呢？是在JettyServerModule中调用的，通过@Provides注解来实现的。同时这个Module还对GuiceContainer进行了Bind，DruidGuiceContainer继承了GuiceContainer，通过Guice将JSR311Resource注解修饰的类都注入进来作为Resource，Resource上就是http接口。所以想要增加http接口只需要写一个Resource类，然后通过Jerseys.addResource添加进来就可以。