生命太短暂,不要去做一些根本没有人想要的东西。本文已被 https://www.yourbatman.cn 收录,里面一并有Spring技术栈、MyBatis、JVM、中间件等小而美的 专栏 供以免费学习。关注公众号【 BAT的乌托邦 】逐个击破,深入掌握,拒绝浅尝辄止。
目录
各位小伙伴大家好,我是A哥。通过本专栏前两篇的学习,相信你对static关键字在Spring/Spring Boot里的应用有了全新的认识,能够解释工作中遇到的大多数问题/疑问了。本文继续来聊聊static关键字更为常见的一种case:使用 @Autowired
依赖注入静态成员(属性)。
在Java中,针对static静态成员,我们有一些最基本的常识:静态变量(成员)它是 属于类 的,而非属于实例对象的属性;同样的静态方法也是属于类的,普通方法(实例方法)才属于对象。而Spring容器管理的都是 实例对象 ,包括它的 @Autowired
依赖注入的均是容器内的对象实例,所以对于static成员是不能直接使用 @Autowired
注入的。
这很容易理解:类成员的初始化较早,并不需要依赖实例的创建,所以这个时候Spring容器可能都还没“出生”,谈何依赖注入呢?
这个示例,你或许似曾相识:
@Component public class SonHolder { @Autowired private static Son son; public static Son getSon() { return son; } }
然后“正常使用”这个组件:
@Autowired private SonHolder sonHolder; @Transaction public void method1(){ ... sonHolder.getSon().toString(); }
运行程序,结果抛错:
Exception in thread "main" java.lang.NullPointerException ...
很明显, getSon()
得到的是一个null,所以给你扔了个NPE。
本文内容若没做特殊说明,均基于以下版本:
1.8 5.2.2.RELEASE
说起 @Autowired
注解的作用,没有人不熟悉, 自动装配 嘛。根据此注解的定义,它似乎能使用在很多地方:
@Target({ElementType.CONSTRUCTOR, ElementType.METHOD, ElementType.PARAMETER, ElementType.FIELD, ElementType.ANNOTATION_TYPE}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface Autowired { boolean required() default true; }
本文我们重点关注它使用在FIELD成员属性上的case,标注在static静态属性上是本文讨论的中心。
说明:虽然Spring官方现在并不推荐字段/属性注入的方式,但它的便捷性仍无可取代,因此在做 业务开发 时它仍旧是主流的使用方式
假如有这样一个场景需求:创建一个教室(Room),需要传入一批学生和一个老师,此时我需要对这些 用户 按照规则(如名字中含有test字样的示为测试帐号)进行数据合法性校验和过滤,然后才能正常走创建逻辑。此case还有以下特点:
阅读完“题目”感觉还是蛮简单的,很normal的一个业务需求case嘛,下面我来模拟一下它的实现。
从UC用户中心获取用户数据(使用本地数据模拟远程访问):
/** * 模拟去远端用户中心,根据ids批量获取用户数据 * * @author yourbatman * @date 2020/6/5 7:16 */ @Component public class UCClient { /** * 模拟远程调用的结果返回(有正常的,也有测试数据) */ public List<User> getByIds(List<Long> userIds) { return userIds.stream().map(uId -> { User user = new User(); user.setId(uId); user.setName("YourBatman"); if (uId % 2 == 0) { user.setName(user.getName() + "_test"); } return user; }).collect(Collectors.toList()); } }
说明:实际情况这里可能只是一个 @FeignClient
接口而已,本例就使用它mock喽
因为过滤测试用户的功能过于 通用 ,并且规则也需要收口,须对它进行封装,因此有了我们的 内部 帮助类 UserHelper
:
/** * 工具方法:根据用户ids,按照一定的规则过滤掉测试用户后返回结果 * * @author yourbatman * @date 2020/6/5 7:43 */ @Component public class UserHelper { @Autowired UCClient ucClient; public List<User> getAndFilterTest(List<Long> userIds) { List<User> users = ucClient.getByIds(userIds); return users.stream().filter(u -> { Long id = u.getId(); String name = u.getName(); if (name.contains("test")) { System.out.printf("id=%s name=%s是测试用户,已过滤/n", id, name); return false; } return true; }).collect(Collectors.toList()); } }
很明显,它内部需依赖于 UCClient
这个远程调用的结果。封装好后,我们的业务Service层任何组件就可以尽情的“享用”该工具啦,形如这样:
/** * 业务服务:教室服务 * * @author yourbatman * @date 2020/6/5 7:29 */ @Service public class RoomService { @Autowired UserHelper userHelper; public void create(List<Long> studentIds, Long teacherId) { // 因为学生和老师统称为user 所以可以放在一起校验 List<Long> userIds = new ArrayList<>(studentIds); userIds.add(teacherId); List<User> users = userHelper.getAndFilterTest(userIds); // ... 排除掉测试数据后,执行创建逻辑 System.out.println("教室创建成功"); } }
书写个测试程序来模拟Service业务调用:
@ComponentScan public class DemoTest { public static void main(String[] args) { ApplicationContext context = new AnnotationConfigApplicationContext(DemoTest.class); // 模拟接口调用/单元测试 RoomService roomService = context.getBean(RoomService.class); roomService.create(Arrays.asList(1L, 2L, 3L, 4L, 5L, 6L), 101L); } }
运行程序,结果输出:
id=2 name=YourBatman_test是测试用户,已过滤 id=4 name=YourBatman_test是测试用户,已过滤 id=6 name=YourBatman_test是测试用户,已过滤 教室创建成功
一切都这么美好,相安无事的,那为何还会有本文指出的问题存在呢?正所谓“不作死不会死”,总有那么一些“追求极致”的选手就喜欢玩花,下面姑且让我猜猜你为何想要依赖注入static成员属性呢?
从上面示例类的命名中,我或许能猜出你的用意。 UserHelper
它被命名为一个工具类,而一般我们对工具类的理解是:
现状是:使用 UserHelper
去处理用户信息还得先 @Autowired
注入它的实例,实属不便。因此你想方设法的想把 getAndFilterTest()
这个方法变为静态方法,这样通过类名便可直接调用而并不再依赖于注入UserHelper实例了,so你想当然的这么“优化”:
@Component public class UserHelper { @Autowired static UCClient ucClient; public static List<User> getAndFilterTest(List<Long> userIds) { ... // 处理逻辑完全同上 } }
属性和方法都添加上static修饰,这样使用方通过类名便可直接访问(无需注入):
@Service public class RoomService { public void create(List<Long> studentIds, Long teacherId) { ... // 通过类名直接调用其静态方法 List<User> users = UserHelper.getAndFilterTest(userIds); ... } }
运行程序,结果输出:
07:22:49.359 [main] INFO org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor - Autowired annotation is not supported on static fields: static cn.yourbatman.temp.component.UCClient cn.yourbatman.temp.component.UserHelper.ucClient 07:22:49.359 [main] INFO org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor - Autowired annotation is not supported on static fields: static cn.yourbatman.temp.component.UCClient cn.yourbatman.temp.component.UserHelper.ucClient ... Exception in thread "main" java.lang.NullPointerException at cn.yourbatman.temp.component.UserHelper.getAndFilterTest(UserHelper.java:23) at cn.yourbatman.temp.component.RoomService.create(RoomService.java:26) at cn.yourbatman.temp.DemoTest.main(DemoTest.java:19)
以为天衣无缝,可结果并不完美,抛异常了。我特意多粘贴了两句info日志,它们告诉了你为何抛出NPE异常的原因: @Autowired不支持标注在static字段/属性上 。
静态变量是属于 类本身 的信息,当类加载器加载静态变量时,Spring的上下文环境 还没有 被加载,所以不可能为静态变量绑定值(这只是最表象原因,并不准确)。同时,Spring也不鼓励为静态变量注入值(言外之意:并不是不能注入),因为它认为这会增加了耦合度,对测试不友好。
这些都是表象,那么实际上Spring是如何“操作”的呢?我们沿着 AutowiredAnnotationBeanPostProcessor
输出的这句info日志,倒着找原因,这句日志的输出在这:
AutowiredAnnotationBeanPostProcessor: // 构建@Autowired注入元数据方法 // 简单的说就是找到该Class类下有哪些是需要做依赖注入的 private InjectionMetadata buildAutowiringMetadata(final Class<?> clazz) { ... // 循环递归,因为父类的也要管上 do { // 遍历所有的字段(包括静态字段) ReflectionUtils.doWithLocalFields(targetClass, field -> { if (Modifier.isStatic(field.getModifiers())) { logger.info("Autowired annotation is not supported on static fields: " + field); } return; ... }); // 遍历所有的方法(包括静态方法) ReflectionUtils.doWithLocalMethods(targetClass, method -> { if (Modifier.isStatic(method.getModifiers())) { logger.info("Autowired annotation is not supported on static methods: " + method); } return; ... }); ... targetClass = targetClass.getSuperclass(); } while (targetClass != null && targetClass != Object.class); ... }
这几句代码道出了Spring为何不给static静态字段/静态方法执行 @Autowired
注入的 最真实原因 :扫描Class类需要注入的元数据的时候,直接选择忽略掉了static成员(包括属性和方法)。
那么这个处理的入口在哪儿呢?是否在这个阶段时Spring真的无法给static成员完成赋值而选择忽略掉它呢,我们继续最终此方法的调用处。此方法唯一调用处是 findAutowiringMetadata()
方法,而它被调用的地方有三个:
调用处一:执行时机较早,在 MergedBeanDefinitionPostProcessor
处理bd合并期间就会解析出需要注入的元数据,然后做check。它会作用于每个bd身上,所以上例中的2句info日志第一句就是从这输出的
AutowiredAnnotationBeanPostProcessor: @Override public void postProcessMergedBeanDefinition(RootBeanDefinition beanDefinition, Class<?> beanType, String beanName) { InjectionMetadata metadata = findAutowiringMetadata(beanName, beanType, null); metadata.checkConfigMembers(beanDefinition); }
调用处二:在 InstantiationAwareBeanPostProcessor
也就是 实例创建好后 ,给属性赋值阶段(也就是 populateBean()
阶段)执行。所以它也是会作用于每个bd的,上例中2句info日志的第二句就是从这输出的
AutowiredAnnotationBeanPostProcessor: @Override public PropertyValues postProcessProperties(PropertyValues pvs, Object bean, String beanName) { InjectionMetadata metadata = findAutowiringMetadata(beanName, bean.getClass(), pvs); try { metadata.inject(bean, beanName, pvs); } ... return pvs; }
调用处三:这个方法比较特殊,它表示对于带有任意 目标实例 (已经不仅是Class,而是实例本身)直接调用的“本地”处理方法实行注入。这是Spring提供给“外部”使用/注入的一个public公共方法,比如给容器外的实例注入属性,还是比较实用的,本文下面会介绍它的使用办法
说明:此方法Spring自己并不会主动调用,所以不会自动输出日志(这也是为何调用处有3处,但日志只有2条的原因)
AutowiredAnnotationBeanPostProcessor: public void processInjection(Object bean) throws BeanCreationException { Class<?> clazz = bean.getClass(); InjectionMetadata metadata = findAutowiringMetadata(clazz.getName(), clazz, null); try { metadata.inject(bean, null, null); } ... }
通过这部分源码,从底层诠释了Spring为何不让你 @Autowired
注入static成员的原因。既然这样,难道就没有办法满足我的“诉求”了吗?答案是有的,接着往下看。
虽然Spring会忽略掉你直接使用 @Autowired + static成员 注入,但还是有很多方法来 绕过 这些限制,实现对静态变量注入值。下面A哥介绍2种方式,供以参考:
方式一:以set方法作为跳板,在里面实现对static静态成员的赋值
@Component public class UserHelper { static UCClient ucClient; @Autowired public void setUcClient(UCClient ucClient) { UserHelper.ucClient = ucClient; } }
方式二:使用 @PostConstruct
注解,在里面为static静态成员赋值
@Component public class UserHelper { static UCClient ucClient; @Autowired ApplicationContext applicationContext; @PostConstruct public void init() { UserHelper.ucClient = applicationContext.getBean(UCClient.class); } }
虽然称作是2种方式,但其实我认为思想只是一个: 延迟为static成员属性赋值 。因此,基于此思想 确切的说 会有N种实现方案(只需要保证你在使用它之前给其赋值上即可),各位可自行思考,A哥就没必要一一举例了。
作为 福利 ,A哥在这里提供一种更为高(zhuang)级(bi)的实现方式供以你学习和参考:
@Component public class AutowireStaticSmartInitializingSingleton implements SmartInitializingSingleton { @Autowired private AutowireCapableBeanFactory beanFactory; /** * 当所有的单例Bena初始化完成后,对static静态成员进行赋值 */ @Override public void afterSingletonsInstantiated() { // 因为是给static静态属性赋值,因此这里new一个实例做注入是可行的 beanFactory.autowireBean(new UserHelper()); } }
UserHelper类 不再需要 标注 @Component
注解,也就是说它不再需要被Spirng容器管理(static工具类确实不需要交给容器管理嘛,毕竟我们不需要用到它的实例),这从某种程度上也是节约开销的表现。
public class UserHelper { @Autowired static UCClient ucClient; ... }
运行程序,结果输出:
08:50:15.765 [main] INFO org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor - Autowired annotation is not supported on static fields: static cn.yourbatman.temp.component.UCClient cn.yourbatman.temp.component.UserHelper.ucClient Exception in thread "main" java.lang.NullPointerException at cn.yourbatman.temp.component.UserHelper.getAndFilterTest(UserHelper.java:26) at cn.yourbatman.temp.component.RoomService.create(RoomService.java:26) at cn.yourbatman.temp.DemoTest.main(DemoTest.java:19)
报错。当然喽,这是我故意的,虽然抛异常了,但是看到我们的进步了没: info日志只打印一句了 (自行想想啥原因哈)。不卖关子了,正确的姿势还得这么写:
public class UserHelper { static UCClient ucClient; @Autowired public void setUcClient(UCClient ucClient) { UserHelper.ucClient = ucClient; } }
再次运行程序, 一切正常 (info日志也不会输出喽)。这么处理的好处我觉得有如下三点:
当然,你也可以这么玩:
@Component public class AutowireStaticSmartInitializingSingleton implements SmartInitializingSingleton { @Autowired private AutowiredAnnotationBeanPostProcessor autowiredAnnotationBeanPostProcessor; @Override public void afterSingletonsInstantiated() { autowiredAnnotationBeanPostProcessor.processInjection(new UserHelper()); } }
依旧可以正常work。这不正是上面介绍的 调用处三 麽,马上就学以致用了有木有,开心吧:smile:。
有这种使用需求的小伙伴需要明晰什么才叫真正的util工具类?若你的工具类存在外部依赖,依赖于Spring容器内的 实例 ,那么它就称不上是工具类,就请不要把它当做static来用,容易玩坏的。你现在能够这么用 恰好是 得益于Spring管理的实例默认都是 单例 ,所以你赋值一次即可,倘若某天真变成多例了呢(即使可能性极小)?
强行这么撸,是有隐患的。同时也打破了优先级关系、生命周期关系,容易让“初学者”感到迷糊。当然若你坚持这么使用也未尝不可,那么请做好相关规范/归约,比如使用上面我推荐的高(zhuang)级(bi)使用方式是一种较好的选择,这个时候 手动管理 往往比自动来得更安全,降低后期可能的维护成本。
@Autowired
注入元数据的时候,Spring工厂/容器明明已经准备好了,理论上已经 完全具备 帮你完成注入/赋值的能力,既然这样,为何Spring还偏要“拒绝”这么干呢?可直接注入static成员不香吗? @Autowired
不能注入static属性,那么static方法呢?@Value注解呢? 本文介绍了Spring依赖注入和static的关系,从使用背景到原因分析都做了相应的阐述,A哥觉得还是蛮香的,对你帮助应该不小吧。
最后,我想对小伙伴说:依赖注入的 主要目的 ,是让容器去产生一个对象的实例然后管理它的生命周期,然后 在生命周期中 使用他们,这会让单元测试工作更加容易(什么?不写单元测试,那你应该关注我喽,下下下个专栏会专门讲单元测试)。而如果你使用静态变量/类变量就 扩大了 使用范围,使得不可控了。这种static field是 隐含共享 的,并且是一种global全局状态,Spring并不推荐你去这么做,因此使用起来务必当心~