【曹工杂谈】Maven IOC 容器-- Guice内部有什么

Google Guice容器内部有什么

前言

Maven系列，好几天没写了，主要是这几天被Google Guice卡住了，本来是可以随便带过Guice，讲讲guice的用法就够了（这个已经讲了，在前面的文章），但是，想着guice作为maven的底层IOC容器，对guice的理解深入一些，对后续的Maven源码学习也会比较有帮助，因此，就在那开始分析guice的源码。

guice作为一个仅次于Spring的IOC容器，代码也不是那么好懂的，毕竟也迭代了十来年了；代码量不少，另外，我感觉代码也有点绕，就看得真心有点打瞌睡。

因为下班回来也9点多了，学习的时间也不多，因此，花了好几天时间来单步debug，有一点点眉目，因此，这里先分享给大家，等后续理解深入了再补充。

针对Guice的源码分析法

一般来说，我debug源码，都是从头开始，单步debug过去，很多时候，这种IOC框架啥的，启动非常复杂，一个小时也跟不完一趟；过程冗长，一篇几千字的文章基本都讲不完，读者也记不住那么多东西，博主也很难讲清那么多东西。

我今天也想着换个思路吧，IOC容器，不是分两个阶段吗，启动时，一般是准备IOC容器；而运行时，就是去容器拿东西。根据我的发现，一般为了保证运行时足够快，都会预先把数据准备好，比如，针对singleton类型的实例，都会预先生成（eager-initilization），存放到容器中，就无需运行时再去生成，归根结底，就是一个空间换时间的方法。

采用这种空间换时间的方法，就会有个问题，就是在数据准备阶段（比如容器初始化阶段），要做的工作相当多，debug过程也非常长；甚至，有时候准备的很多数据，对于我们的场景，根本用不上。

因此，下面我会先给大家看看，初始化成功后的容器，是什么样的；再去简单分析背后的启动过程。

简单demo

一共三个类。

public interface HelloInterface {
    void hello();
}

public class HelloInterfaceImpl implements HelloInterface {
    @Override
    public void hello() {
        System.out.println("hello world");
    }
}

再下边是启动类：

这个启动类，也就是三个部分：

• 第一个部分，就是配置：HelloInterface这个class，要映射到 HelloInterfaceImpl这个实现类，后续，容器才能根据HelloInterface来new一个HelloInterface的实例出来。
• 初始化容器
• 运行时，从容器获取HelloInterface的对象

容器中有什么

假设我们跳过初始化容器的阶段，不关心容器如何构造，如何启动，只看：构造好的容器，是什么样的。

// 构造容器
Injector injector = Guice.createInjector(module);

在执行完上面这句后，容器就已经初始化完毕，此时，我们打上断点，看看容器的内部：

类型

真实类型是：

// Default Injector implementation.
final class InjectorImpl implements Injector, Lookups

从它实现的接口com.google.inject.Injector来看，主要有以下一些核心方法：

// 获取当前容器内的全部绑定关系
Map<Key<?>, Binding<?>> getBindings();
// 根据key，获取这个key对应的绑定关系。key其实基本就是一个接口的Class类名
<T> Binding<T> getBinding(Key<T> key);
// 根据class，获取这个class对应的绑定
<T> Binding<T> getBinding(Class<T> type);

// 根据key，获取对应的工厂类
<T> Provider<T> getProvider(Key<T> key);
// 根据class，获取对应的工厂类
<T> Provider<T> getProvider(Class<T> type);

//根据key/class，直接获取对应的实例
<T> T getInstance(Key<T> key);
<T> T getInstance(Class<T> type);

大家看到这里，是不是觉得和Spring的容器很像呢？

字段

• 父容器

  final InjectorImpl parent;
  

  类似于spring，spring也有父子容器的概念；大体就是，当前容器找不到实例，还可以去父容器找

  我们这个demo里，parent是null

• 绑定map

  final ListMultimap<TypeLiteral<?>, Binding<?>> bindingsMultimap;
  

  存储了一些绑定关系，包括了三个默认的绑定，如：容器injector本身、日志logger、stage。

  

• 容器选项

  final InjectorOptions options;
  

  

  这边是一些配置项，比如jitdisabled，禁止隐式依赖。禁止后，你要向容器获取Class X的实例，那么必须先配置X对应的实例化方式，不会再默认尝试调用Class X的构造器（如果有的话）

• 隐式绑定

  final Map<Key<?>, BindingImpl<?>> jitBindings = Maps.newHashMap();
  

  比如我们的这个实现类，就是个隐式绑定，因为我们没配置如何实例化HelloInterfaceImpl。

  

• 构造器缓存

    final ConstructorInjectorStore constructors = new ConstructorInjectorStore(this);
  

  比如我们实现类的构造器，就被缓存了。

  

• 内部状态：state

  看了以上几个字段，感觉也没有很特别。其实，真正重要的字段，是下面将出场的这个。

  final State state;
  

  大家看下图，会发现state下有不少字段，主要就有：每个class对应的绑定（value就是这个class的实例化方式）、还有我们代码里配了个切面也在这里；基本上，这里才是真正的容器的各种数据的存放处

  接下来，我们再看看这个绑定关系的map。key就是对应的接口类，value就是说：怎么去实例化一个这个类型的实例出来，所以呢，guice内部，为了统一，基本把value这部分统一成了一个工厂。如下：

  

  而工厂类里是什么样呢？

  

  就是包含了对应的实现类的构造器了。

  在真正要找容器获取这个HelloInterface的实例时，就可以找到HelloInterfaceImpl的构造函数，从而构造一个实例出来。

不同的binding方式，内部不同的工厂类

当我们配置了一个如下的绑定关系时：

binder.bind(String.class).toInstance("xxx");

此时，内部又是什么样呢？

这里，我们发现内部工厂internalFactory的类型，和之前也不太一样了。同时，下图可以看见，工厂内部直接存了这个String实例的值。

总之呢，也是保证后续直接就能在容器需要一个String类型实例时，找到“xxx”这个对象返回回去。

从容器中获取

容器初始化好了，怎么获取呢？即如下代码怎么执行呢？

HelloInterface instance = injector.getInstance(HelloInterface.class);

我们稍微跟了下，发现就会走到如下地方，会去查询state内部的显示绑定map。

获取到binding后，即取出internalFactory，然后构造/取出对象即可。

总结

不知道大家清晰一点了没，希望对大家有帮助。后续会视情况，再看看是否分析构造容器的源码。