184 条查询结果
近期,阿里巴巴CTO线卓越工程小组举办了阿里巴巴第一届单元测试比赛《这!就是单测》并取得了圆满成功。本人有幸作为评委,在仔细地阅读了各个小组的单元测试用例后,发现了两大单元测试问题: 1、无效验证问题: 不进行有效地验证数据对象、抛出异常和调用方法。 2、测试方法问题: 不知道如何测试某些典型案例,要么错误地测试、要么不进行测试、要么利用集成测试来保证覆盖率。比如: 错误地测试:利用测试返回节点占比来测试随机负载均衡策略; 不进行测试:没有人针对虚基类进行单独地测试; 利用集成测试:很多案例中,直接注入真实依赖对象,然后一起进行集成测试。 针对无效验证问题,在我的文章《那些年,我们写过的无效单元测试》中,介绍了如何识别和解决单元测试无效验证问题,这里就不再累述了。在本文中,作者收集了一些的Java单元测试典型案例,主要是为了解决这个测试方法问题。
最近同事说到 Java 的ParallelGCThreads 参数,我翻了下 jdk8 的代码,发现 ParallelGCThreads 的参数默认值如下: 如果 cpu 核心数目少于等于 8,则 GC 线程数量和 CPU 数一致 如果 cpu 核心数大于 8,则前 8 个核,每个核心对应一个 GC 线;其他核,每 8 个核对应 5 个 GC 线程 但是被提醒,发现即使在分配 4 核的容器上,GC 线程数也为 38。然后就想到应该和容器的资源限制有关—— jvm 可能无法觉察到当前容器的资源限制。 翻了下代码,发现最新版本的 java 是能感知容器的资源限制的,就按照jdk版本再翻了下代码。