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 {
@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 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接口的泛型类。看一下bind方法：
public static void bind(
Binder binder,
String propertyBase,
Class clazz,
Key instanceKey,
Key> supplierKey) {
binder.bind(supplierKey).toProvider((Provider) of(propertyBase, clazz)).in(LazySingleton.class);
binder.bind(instanceKey).toProvider(new SupplierProvider(supplierKey));
}
这个bind方法是把Supplier
public Supplier 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
public class SupplierProvider implements Provider {
private final Key> supplierKey;
private Provider> supplierProvider;
public SupplierProvider(Key> 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 ScopedBindingBuilder createChoiceWithDefault(
Binder binder,
String property,
Key interfaceKey,
Key defaultKey,
String defaultPropertyValue) {
return binder.bind(interfaceKey).toProvider(new ConfiggedProvider(interfaceKey, property, defaultKey, defaultPropertyValue));
}
这个ConfiggedProvider是干什么的呢？
static class ConfiggedProvider implements Provider {
private final Key key;
private final String property;
private final Key defaultKey;
private final String defaultPropertyValue;
private Injector injector;
private Properties props;
ConfiggedProvider(
Key key,
String property,
Key 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> implsMap;
if (key.getAnnotation() != null) {
implsMap = (Map>) injector.getInstance(Key.get(mapType, key.getAnnotation()));
} else if (key.getAnnotationType() != null) {
implsMap = (Map>) injector.getInstance(Key.get(mapType, key.getAnnotation()));
} else {
implsMap = (Map>) injector.getInstance(Key.get(mapType));
}
String implName = props.getProperty(property);
if (implName == null) {
implName = defaultPropertyValue;
}
final Provider 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 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添加进来就可以。