提到Spring依赖注入,大家最先想到应该是@Resource和@Autowired,很多文章只是讲解了功能上的区别,对于Spring为什么要支持两个这么类似的注解却未提到,属于知其然而不知其所以然。不知大家在使用这两个注解的时候有没有想过,@Resource又支持名字又支持类型,还要@Autowired干嘛,难道是Spring官方没事做了? 真的是没事做了吗?读了本文你将会了解到: @Resource和@Autowired来源 Spring官方为什么会支持这两个功能如此相似的注解? 为什么@Autowired属性注入的时候Idea会曝出黄色的警告? @Resource和@Autowired推荐用法
在 JDK 9 之前,Java 基本上平均每三年出一个版本。但是自从 2017 年 9 月份推出 JDK9 到现在,Java 开始了疯狂更新的模式,基本上保持了每年两个大版本的节奏。从 2017 年至今,已经发布了一个版本到了 JDK 19。其中包括了两个 LTS 版本(JDK11 与 JDK17)。除了版本更新节奏明显加快之外,JDK 也围绕着云原生场景的能力,推出并增强了一系列诸如容器内资源动态感知、无停顿GC(ZGC、Shenandoah)、运维等等云原生场景方面的能力。这篇文章是 EDAS 团队的同学在服务客户的过程中,从云原生的角度将相关的功能进行整理和提炼而来。希望能和大家一起认识一个新的 Java 形态。 上一篇 (《 从 JDK 9 到 19,我们帮您提炼了和云原生场景有关的能力列表(上) 》)我们讲了在整个演进过程中针对运行时模型和运维能力的一些重要变化,这一节我们主要是来讲讲内存相关的变化。
近期,阿里巴巴CTO线卓越工程小组举办了阿里巴巴第一届单元测试比赛《这!就是单测》并取得了圆满成功。本人有幸作为评委,在仔细地阅读了各个小组的单元测试用例后,发现了两大单元测试问题: 1、无效验证问题: 不进行有效地验证数据对象、抛出异常和调用方法。 2、测试方法问题: 不知道如何测试某些典型案例,要么错误地测试、要么不进行测试、要么利用集成测试来保证覆盖率。比如: 错误地测试:利用测试返回节点占比来测试随机负载均衡策略; 不进行测试:没有人针对虚基类进行单独地测试; 利用集成测试:很多案例中,直接注入真实依赖对象,然后一起进行集成测试。 针对无效验证问题,在我的文章《那些年,我们写过的无效单元测试》中,介绍了如何识别和解决单元测试无效验证问题,这里就不再累述了。在本文中,作者收集了一些的Java单元测试典型案例,主要是为了解决这个测试方法问题。