从零实现一个 Java 微框架 - IoC
前言
IoC 容器在之前的文章中就有说明。
之前的文章其实是基于 PHP 的,虽然思想是类似的,不过还是再次说明一下吧。
IoC 是什么?
IoC(Inversion of control,控制反转),它是一种思想而不是一个技术实现(组件),通常也和 DI(Dependency Injection,依赖注入)一同出现,这两者其实可以看成一个东西。不过 DI 更多的是指注入的过程或方式(B 对象注入到了 A),IoC 更多的是指这种反转思想(B 对象交给了外部管理)。
为了更好的描述 IoC,这里 我们就引入一个样例吧,就拿我前几天购买的一个阅读器来说吧。既然是阅读器,那么我们肯定是要有个阅读器的类:
_16public class BookReader {_16_16 private final BookStorage storage;_16_16 public BookReader() {_16 this.storage = new FileBookStorage();_16 }_16_16 public String read(final String name) {_16 return this.storage.getBook(name).getContent();_16 }_16_16 public void put(final Book book) {_16 this.storage.registerBook(book);_16 }_16}
其中,我们需要一个 BookStorage
来存储阅读器里存放的书,然后阅读器拥有 read
阅读和 put
存新书的功能。
通常情况下我们会将所依赖的 BookStorage
的对象直接在构造器中 new
出来,这是最简单且直接的使用方式。但是这种简单的方式也导致了一种问题,如果哪天需要开发一个基于网络的阅读器,那么我们的存储不再是 FileBookStorage
,而应该是 NetworkBookStorage
,此时为了能制作出网络阅读器我们就不得不重新写一个 BookReader
类,然后重新实现内部的逻辑。
这时候肯定有人会提出应该把 BookStorage
从外面通过构造器传入不就可以了?其实当你提出这个疑问的时候你已经可以说了解 IoC 了,这种通过外部传入依赖的方式就称为依赖注入,也就是控制反转的思想。
控制反转中的控制指的是对对象管理、创建的权力;反转指的是将这个控制权交给外部环境,至于外部环境可以是几 行代码、IoC 容器。使用者只负责使用依赖,至于依赖是如何构造、管理的这就不关使用者的事了。
利用 IoC 思想改造后的构造器如下:
_3public BookReader(final BookStorage bookStorage) {_3 this.storage = bookStorage;_3}
改造后虽然我们丢失了创建 BookStorage
的功能,不过相对的这种方式解决了各部件间强耦合的问题,我们可以通过给 BookReader
传入不同的 BookStorage
来灵活的实现及复用。
IoC 容器
**IoC 容器(IoC Container)**一般也称为 IoC 服务提供者(IoC Service Provider),简单的说就是用来自动化创建依赖以及管理依赖的工厂。由于经常被简称为 IoC 所以也很 多人会认为 IoC 就是 IoC 容器,其实 IoC 容器只是用来方便实现 IoC 思想的一种工具。
最简单的 IoC 容器包括了以下几种功能:
- 对象的构建管理:当我们需要某个对象的时候无需关心它是如何被创建出来的、需要什么依赖关系,这个过程就是由 IoC 负责的。
- 对象的依赖绑定:为了对对象进行构建,IoC 容器需要知道对象的依赖关系。
- 对象的存储管理:既然是容器那就需要有存储的功能,IoC 容器可以依照需求存储单例对象或依赖(需要存储的依赖不单单是 Bean 对象)。
对于现在的 IoC 容器来说注册对象管理信息一般有以下 3 种:
- 直接编码:即调用注册方法
regsiter
将对象注册到 IoC 容器中。 - 配置文件:在 Spring IoC 等容器一般都存在这种配置方式,通过配置文件配置 IoC 容器的对象及依赖关系。
- 元数据:元数据的方式则较为广泛,注解、类型、变量名等等都可以作为元数据来指引 IoC 容器注册和使用对象。
通常情况 IoC 容器有以下几种注入方式:
- 构造器注入
- Setter 方式注入
- 字段注入:字段注入可以归入 Setter 注入,有一定侵入性,是利用反射直接设置字段值的方式。
- 接口注入:接口注入是比较特殊的,带有侵入性,不一定所有 IoC 容器都支持,是通过实现接口方法来取得注入的依赖。
设计 IoC 容器
既然已经知道了 IoC 容器需要的功能,那么就可以开始设计我们自己的 IoC 容器了。文章可能会结合一些 Spring 的东西。不过本篇文章主要是写我自己的 Java 框架,所以 Spring 就点到为止了,如需深入的话可以看别的源码解析的文章或者书籍。比如这篇大佬写的文章就还不错。
XK-Java IoC 容器的设计较为简单,其设计最初的参考是来自 Laravel,不过经过后续不断的重构已经比较类似 Spring IoC 了。
XK-Java IoC 容器所需要存储的数据:
- 实例元信息(Binding, BeanDefinition):保存实例的一些信息,如作用域、名称、注解等一系列容器需要使用的信息。
- 实例(Instance, Singleton):由于有些实例是以单例的状态存储的,所以容器还需要为这些实例提供存储。
- 别名(Alias):实例可以有别的名称。
- 类型索引(BeanNameByType):通常情况下我们都不会对每个 Bean 都进行配置,所以 IoC 容器一般是使用类型来进行自动注入的,为了能快速的查询到指定类型的依赖,我们需要对每个绑定到 IoC 容器的依赖都进行类型遍历,然后建 立索引。
- 注入器 & Bean 处理器(Injector & BeanProcessor):为了方便扩展和实现额外的功能就不能把构建的流程封闭到 IoC 容器,所以需要通过注入器或者 Bean 处理器来处理实例或依赖。
- 作用域(Context, Scope):IoC 容器不可能只存储某个作用域的实例,通常有多种作用域,比如单例域、非单例、请求域等多种作用域来存储实例。
- 临时依赖(DataBinder):由于部分情况需要临时注入一些依赖,比如 HTTP 的请求参数,这就需要有一个数据容器来临时存储这些参数依赖。
XK-Java IoC 容器所需要的功能:
- 绑定:用于将依赖绑定到容器中,依赖可以是已经构建完成的实例、立即值、工厂类等等。对应
bind
、doBind
方法。 - 构建:当某个依赖被依赖的时候,而且依赖没有构建的时候就需要对依赖进行构建。对应
doBuild
方法。 - 获取:当我们需要某个实例的时候,就需要从 IoC 容器获取。对应
make
、doMake
方法。 - 销毁:当依赖被从容器删除,或者容器关闭的时候就需要对依赖进行销毁操作,如关闭连接池等等的操作。对应
remove
、doRemove
方法。
实现
有了大致的设计我们就可以开始动工了。
首先需要准备一些周边的类和接口,以下这些周边类是属于 IoC 的一部分,有些其他的类,如 MergedAnnotation,就不在这里说明了。
- TypeProvider:为实现集合、Map 等复合类型注入的类型提供器。因为 Java 有泛型擦除的问题,无法简单的保留泛型,需要从
Field
等类中读取然后保存传递到容器中。 - TypeWrapper:
TypeProvider
的实现类。 - FactoryBean:工厂 Bean,作用和 Spring 的类似,用于创建 Bean 的工厂。
- ObjectFactory:作用和 Spring 类似,用于延迟获取 Bean,不过在本框架也用于 Cglib 代理。
- ObjectProvider:作用和 Spring 类似,相当于高级的
ObjectFactory
。 - AnnotatedEntry、ClassProperty、ConstructorContext、InjectContext、ParameterContext:一些包装类。
- ScopeType:就一个静态类,存放内置作用域名称的常量。
有了上面这些周边类,就可以进入下一部分了。
DataBinder
由于 XK-Java 的设计与 Spring 有所不同。在 XK-Java 的设计里,所有需要注入的(如注入单例,注入请求参数) Java 实例都应该由 IoC 容器负责构建。通常情况下我们有可能会临时设置一些依赖,而又不希望这些临时的依赖托管到容器里,这时候就需要 DataBinder
来负责存储。
_19// see: https://github.com/syfxlin/xkjava/blob/36b1ca22c86790b93e79a00c5b6c3e031ad6139b/xkjava-framework/src/main/java/me/ixk/framework/ioc/binder/DataBinder.java_19public interface DataBinder {_19 /**_19 * 获取实例_19 *_19 * @param name 实例名_19 * @param type 实例类型_19 * @param annotation 注解_19 * @param <T> 实例类型_19 * @param container 容器_19 * @return 实例_19 */_19 <T> T getObject(_19 String name,_19 TypeWrapper<T> type,_19 MergedAnnotation annotation,_19 Container container_19 );_19}
DataBinder
被设计为简单的依赖存储容器,所以无需非 常多的元信息,通过实例的名称、类型、注解即可取得其存储的实例。可以认为是缩小版的 IoC 容器。
DefaultDataBinder
是默认的实现类:
_57// see: https://github.com/syfxlin/xkjava/blob/36b1ca22c86790b93e79a00c5b6c3e031ad6139b/xkjava-framework/src/main/java/me/ixk/framework/ioc/binder/DefaultDataBinder.java_57public class DefaultDataBinder implements DataBinder {_57 // 实例容器 <名称,实例>_57 private final Map<String, Object> objects = new HashMap<>();_57 // 类型对应的实例名称 <类型,<名称>>_57 private final Map<Class<?>, List<String>> objectTypes = new HashMap<>();_57_57 @Override_57 public <T> T getObject(_57 String name,_57 final TypeWrapper<T> type,_57 final MergedAnnotation annotation,_57 final Container container_57 ) {_57 // 取得 @DataBind 注解,@DataBind 注解可以控制注入的实例_57 final DataBind dataBind = annotation == null_57 ? null_57 : annotation.getAnnotation(DataBind.class);_57 if (dataBind != null && dataBind.name().length() != 0) {_57 // 如果 DataBind 设置要取得的实例的名称就以 DataBind 为准_57 name = dataBind.name();_57 }_57 final Class<T> clazz = type.getClazz();_57 // 取得对应名称的实例_57 Object object = this.objects.get(name);_57 // 如果取得的实例类型不符,那就放弃这个实例(需要注意,DataBind 被设计为不允许类型转换)_57 if (object != null && !clazz.isInstance(object)) {_57 object = null;_57 }_57 if (object == null) {_57 // 如果通过名称找不到就尝试通过类型查找_57 final List<String> list = this.objectTypes.get(clazz);_57 final String objectName;_57 if (list == null || list.isEmpty()) {_57 // 如果没找到就使用默认的名称,即类名首字母小写后的名称_57 objectName = container.typeToBeanName(clazz);_57 } else {_57 objectName = list.get(0);_57 }_57 object = this.objects.get(objectName);_57 }_57 if (object == null) {_57 // 如果还是没 取得,就尝试使用 IoC 容器构建(递归构建)_57 object = container.make(name, type, this);_57 }_57 if (_57 object == null &&_57 dataBind != null &&_57 DataBind.EMPTY.equals(dataBind.defaultValue())_57 ) {_57 // 构建还是失败了(真惨),那就使用 DataBind 设置的默认值_57 object = dataBind.defaultValue();_57 }_57 // 类型转换(需要注意,这只是简单的转换)_57 return Convert.convert(clazz, object);_57 }_57}
Context
Context
类似于 Spring 的 Scope
,用于作用域隔离,比如线程私有实例,请求私有实例等等。具体的可以参考 Spring 的 Scope
的作用。
_75// see: https://github.com/syfxlin/xkjava/blob/36b1ca22c86790b93e79a00c5b6c3e031ad6139b/xkjava-framework/src/main/java/me/ixk/framework/ioc/context/Context.java_75public interface Context {_75 /**_75 * 是否是共享的,即单例_75 *_75 * @return 是否_75 */_75 default boolean isShared() {_75 return true;_75 }_75_75 /**_75 * 该 Context 是否启动,一般的 Context 只要 new 后就会启动 但是如果是 ThreadLocal 则需要另行启动_75 *_75 * @return 是否启动_75 */_75 default boolean isCreated() {_75 return true;_75 }_75_75 /**_75 * 是否需要代理_75 *_75 * @return 是否需要代理_75 */_75 default boolean useProxy() {_75 return false;_75 }_75_75 /**_75 * 获取所有实例_75 *_75 * @return 所有实例_75 */_75 ConcurrentMap<String, Object> getInstances();_75_75 /**_75 * 获取实例_75 *_75 * @param name 实例名称_75 * @return 实例_75 */_75 default Object get(final String name) {_75 return this.getInstances().get(name);_75 }_75_75 /**_75 * 删除实例_75 *_75 * @param name 实例名称_75 */_75 default void remove(final String name) {_75 this.getInstances().remove(name);_75 }_75_75 /**_75 * 设置实例_75 *_75 * @param name 名称_75 * @param instance 实例_75 */_75 default void set(final String name, final Object instance) {_75 this.getInstances().put(name, instance);_75 }_75_75 /**_75 * 是否存在实例_75 *_75 * @param name 实例名称_75 * @return 是否存在_75 */_75 default boolean has(final String name) {_75 return this.getInstances().containsKey(name);_75 }_75}
可以看到 Context
其实就是一个类似 Map
的容器,只不过有些其他的方法:
isShared
方法用于确定是否是单例,如果是单例 IoC 容器会在构建实例完后将单例存入Context
。isCreated
方法用于确定实例是否启动,避免在未启动的时候错误使用。useProxy
方法用于确定实例是否需要 Cglib 代理来实时获取最新的值,避免发生使用旧对象情况,或者将 Request 作用域对象注入到 Singleton 作用域导致线程不安全。 有了接口自然有实现类,以下是几个不同场景的实现类,这几个实现类由于代码简单就不细说了:- SingletonContext:单例作用域,里面就是一个简单的
ConcurrentHashMap
。 - PrototypeContext:原型作用域,不存储实例,是非共享的。
- RequestContext:请求作用域,这个作用域和 SessionContext 一样比较特殊,是存储于对应作用域的对象里,比如 Request 是存储于
HttpServletRequest
的 Attribute 里,Session 则存储于HttpSession
里。
Binding
Binding
是实例元信息的实现类,与 Spring 中的 BeanDefinition
类似,不过由于不需要太多的功能就只保存了几种元信息:
- 作用域名称(scope):实例对应的作用域名称。
- 名称(name):实例名称,全局唯一。
- 类型及类注解(instanceTypeEntry):实例的类型及标记在该类上的组合注解。
- 是否是主要的实例(primary):如果是主要注解,当通过类型获取实例,同时该类型下有多个不同的实例,则优先使用
primary
为true
的实例。 - 额外信息(bindingInfos):带软引用缓存的一些信息,有 init-destory 对应的方法反射和 autowired 需要注入的方法,以及字段和方法的反射以及注解。同类型并且有缓存的情况下就不需要再扫描。
除了元信息外 Binding
还保存了一些其他的数据:
- Context:作用域,为了
Binding
内部方法方便操作,避免要使用的时候从 IoC 容器中获取。 - FactoryBean:创建实例的工厂方法,如果未设置 IoC 容器会默认使用 doBuild 方法构建实例。
- Mutex:
Binding
的互斥量(锁)用于避免多次初始化单例使用。将互斥量分散到不同的Binding
中,避免使用唯一互斥量导致大量阻塞的发生。同时单例也采用双重检查模式,避免每次获取的时候都锁住互斥量导致阻塞。
数据部分说完了就开始看方法吧,首先是初始化,初始化就是对 Binding
内的字段进行赋值,扫描对应类型的方法、注解等等的信息,对于消耗性能的扫描部分则使用软引用,空间换时间,避免重复扫描,同时在内存不足的时候可以时间换空间,一定程度避免 OOM 发生。
然后 Binding
里剩下的重要操作就 是对实例的操作了:
_45// see: https://github.com/syfxlin/xkjava/blob/36b1ca22c86790b93e79a00c5b6c3e031ad6139b/xkjava-framework/src/main/java/me/ixk/framework/ioc/entity/Binding.java_45public class Binding {_45 public Object getSource() {_45 // 双重检查获取,因为此时实例可能在构建_45 final Object source = this.getSourceUnsafe();_45 if (source == null) {_45 synchronized (this.getMutex()) {_45 return this.getSourceUnsafe();_45 }_45 }_45 return source;_45 }_45_45 public Object getSource(final boolean proxy) {_45 // 是否使用代理,如果使用代理则利用 Cglib 进行代理,避免引用旧实例,否则就直接取得未代理的实例_45 // 因为执行方法的时候,实际上是每次都使用 getSource 方法取出最新的实例,然后执行_45 // 代理需要满足所有条件才会生效:_45 // 1. 是单例_45 // 2. Context 的作用域配置了需要代理_45 // 3. 注入的类型需要代理,在 TypeWrapper 配置(典型的就是 Field)_45 if (proxy && this.useProxy() && this.isShared()) {_45 return ReflectUtils.proxyObjectFactory(_45 (ObjectFactory<Object>) this::getSource,_45 this.getType()_45 );_45 } else {_45 return this.getSource();_45 }_45 }_45_45 private Object getSourceUnsafe() {_45 // 获取实例前需要判断 Context 是否已经启动,如果未启动就直接返回 null,避免 NPE。_45 return this.isCreated() ? this.context.get(name) : null;_45 }_45_45 public void setSource(final Object instance) {_45 // 设置实例的时候锁住互斥量_45 synchronized (this.getMutex()) {_45 // 要确定是单例才可以存入 Context,否则就不能存入_45 if (this.context.isShared()) {_45 this.context.set(name, instance);_45 }_45 }_45 }_45}
Injector
与 Spring 不同的是,XK-Java 为了更好的扩展性添加了**注入器(Injector)**的设计,其作用仅作为对实例或参数进行注入。目前共有两种类型的 Injector
:
- ParameterInjector:用于参数注入的注入器。
- InstanceInjector:用于实例注入的注入器。
添加注入器的方式非常简单,只需要给注入器的类添加 @Injector
注解,注解扫描器会自动识别注入器并添加到 IoC 容器中。同时可以使用 @Order
注解来对注入器进行排序。
DefaultParameterInjector
是默认的参数注入器,其负责通过参数的元信息构建或获取参数,然后让 IoC 容器可以构建实例或者调用方法:
注入规则:
- 标记了
@DataBind
方法。利用@DataBind
的一些限制查找依赖注入。 - 标记了
@Value
方法。使用@Value
的表达式进行查找注入。 - 未标记任何注解。使用
DataBinder
进行注入。
_86// see: https://github.com/syfxlin/xkjava/blob/36b1ca22c86790b93e79a00c5b6c3e031ad6139b/xkjava-framework/src/main/java/me/ixk/framework/ioc/injector/DefaultParameterInjector.java_86public class DefaultParameterInjector implements ParameterInjector {_86 @Override_86 public Object[] inject(_86 Container container,_86 Object[] dependencies,_86 ParameterContext context_86 ) {_86 // 通过 Parameter 的上下文取得参数反射对象、名称、注解等信息_86 final ParameterEntry[] entries = context.getParameterEntries();_86 for (int i = 0; i < entries.length; i++) {_86 // ParameterEntry 中有个 changed 的标记用于标记是否已经设置_86 // 如果已经设置则不需要使用 DefaultParameterInjector 再次设置_86 // 当然这个标记要靠 ParameterInjector 是否遵守_86 if (entries[i].isChanged()) {_86 continue;_86 }_86 Parameter parameter = entries[i].getElement();_86 String parameterName = entries[i].getName();_86 MergedAnnotation annotation = entries[i].getAnnotation();_86 // 获取 @DataBind 注解,由于 DefaultParameterInjector 并不只用于构造器,所以这个注解还是需要的_86 DataBind dataBind = annotation.getAnnotation(DataBind.class);_86 // 获取 @Value 注解_86 final Value value = annotation.getAnnotation(Value.class);_86 if (value != null) {_86 // 如果设置了 @Value 注解则优先使用 @Value 注解_86 final InjectContext injectContext = context.getContext();_86 // 利用 SpEL 解析 @Value 里的表达式,具体看源码,就是委托给 BeanExpressionResolver 解析_86 dependencies[i] =_86 this.resolveExpression(_86 value,_86 injectContext.getType(),_86 // 获取从 PropertiesProcessor 里设置的 properties 和 prefix_86 // PropertiesProcessor 是 BeforeInjectProcessor,会在 Injector 之前执行_86 injectContext.getData(_86 PropertiesProcessor.PROPERTIES_86 ),_86 injectContext.getData(_86 PropertiesProcessor.PROPERTIES_PREFIX_86 ),_86 container_86 );_86 } else {_86 // 否则就使用当前的 DataBinder 来取得依赖_86 // 默认是 DefaultDataBinder_86 dependencies[i] =_86 context_86 .getBinder()_86 .getObject(_86 parameterName,_86 // 将 Parameter 封装起来是为了传递泛型信息_86 TypeWrapper.forParameter(parameter),_86 annotation,_86 container_86 );_86 }_86 if (_86 dependencies[i] == null &&_86 dataBind != null &&_86 dataBind.required()_86 ) {_86 // 如果这个参数是必须要注入的,但是未查找到依赖则抛出 NPE_86 final NullPointerException exception = new NullPointerException(_86 "Target [" +_86 context.getExecutable().getDeclaringClass().getName() +_86 "@" +_86 context.getExecutable().getName() +_86 "(" +_86 parameterName +_86 ")] is required, but inject value is null"_86 );_86 log.error(_86 "Target [{}@{}({})] is required, but inject value is null",_86 context.getExecutable().getDeclaringClass().getName(),_86 context.getExecutable().getName(),_86 parameterName_86 );_86 throw exception;_86 }_86 // 不管有没有注入完成都设置 changed 标记,表示已经处理过了_86 // DefaultParameterInjector 是优先级最低的注入器,所以设不设置都一样,不过还是遵守标准吧_86 entries[i].setChanged(true);_86 }_86 return dependencies;_86 }_86}
DefaultPropertyInjector
是默认的字段(成员)注入器,与 PropertiesValueInjector
一同作用,用于对实例字段进行注入:
注入规则: