之前经常遇到的问题是，排查问题需要挂arthas，但客户用的是JRE，没法挂载arthas。就只能让客户更换成JDK，再重新部署、排查问题。 很多有用的现场，在这个过程中也会丢失，最终导致问题排查效率降低。于是就探索了下如何在JRE环境中，使用artahs。

46 技术 lddgo 分享于 2023-02-14

astjson是阿里开发的Java语言编写的高性能JSON库，本文总结了Fastjson使用时的一些注意事项，并简单分析了Fastjson的底层工作原理，结合具体的验证代码以及跟Jackson的对比，希望能帮助大家充分理解Fastjson的使用。

53 技术 lddgo 分享于 2023-02-10

因工作需要，需要对java引入动态脚本的支持，当前可实现的动态脚本可选择的空间非常多，但是由于工作特性，作者需要满足一些特征（后面详述），于是把希望在网上看能否找到一些信息。网上针对脚本对比评测的文章有很多，包括涉及类似javascript、groovy、python、ruby等各种脚本，但是大部分为单一测试，且符合当前工作需求的评测较少。组合测试的又不太具有针对性，故作者结合工作场景有针对性的对部分动态脚本进行一期简单的性能评测。

48 技术 lddgo 分享于 2023-02-09

近期，阿里巴巴CTO线卓越工程小组举办了阿里巴巴第一届单元测试比赛《这！就是单测》并取得了圆满成功。本人有幸作为评委，在仔细地阅读了各个小组的单元测试用例后，发现了两大单元测试问题： 1、无效验证问题： 不进行有效地验证数据对象、抛出异常和调用方法。 2、测试方法问题： 不知道如何测试某些典型案例，要么错误地测试、要么不进行测试、要么利用集成测试来保证覆盖率。比如： 错误地测试：利用测试返回节点占比来测试随机负载均衡策略； 不进行测试：没有人针对虚基类进行单独地测试； 利用集成测试：很多案例中，直接注入真实依赖对象，然后一起进行集成测试。 针对无效验证问题，在我的文章《那些年，我们写过的无效单元测试》中，介绍了如何识别和解决单元测试无效验证问题，这里就不再累述了。在本文中，作者收集了一些的Java单元测试典型案例，主要是为了解决这个测试方法问题。

44 技术 lddgo 分享于 2023-02-08

清代谴责小说家吴趼人在《痛史》中写道：“卷帙浩繁，望而生畏。” 意思是：“ 一部书的篇幅太长，让人看见就害怕。”编写单元测试用例也是如此，如果单元测试用例写起来又长又复杂，自然而然地会让人“望而生畏”，于是开始反感甚至于最终放弃。为了便于Java单元测试的推广，作者总结了十余种测试用例的简化方法，希望能够让大家编写单元测试用例时——“化繁为简、下笔如神”。

42 技术 lddgo 分享于 2023-02-02

JDK已经如火如荼的更新到了JDK 19，集团内也在推AJDK 11的升级，升级已然是一个大趋势。本文主要是对体育营销场景升级JDK 11，进行了整理与总结，希望对大家有所帮助。

38 技术 lddgo 分享于 2023-02-01

从 Java Agent 报错开始，到 JVM 原理，到 glibc 线程安全，再到 pthread tls，逐步探究 Java Agent 诡异报错。

40 技术 lddgo 分享于 2023-02-01

最近同事说到 Java 的ParallelGCThreads 参数，我翻了下 jdk8 的代码，发现 ParallelGCThreads 的参数默认值如下： 如果 cpu 核心数目少于等于 8，则 GC 线程数量和 CPU 数一致 如果 cpu 核心数大于 8，则前 8 个核，每个核心对应一个 GC 线；其他核，每 8 个核对应 5 个 GC 线程 但是被提醒，发现即使在分配 4 核的容器上，GC 线程数也为 38。然后就想到应该和容器的资源限制有关—— jvm 可能无法觉察到当前容器的资源限制。 翻了下代码，发现最新版本的 java 是能感知容器的资源限制的，就按照jdk版本再翻了下代码。

42 技术 lddgo 分享于 2023-02-01

在 JDK 9 之前，Java 基本上平均每三年出一个版本。但是自从 2017 年 9 月分推出 JDK9 到现在，Java 开始了疯狂更新的模式，基本上保持了每年两个大版本的节奏。从 2017 年至今，已经发布了 十一个版本到了 JDK 19。其中包括了两个 LTS 版本（JDK11 与 JDK17）。除了版本更新节奏明显加快之外，JDK 也围绕着云原生场景的能力，推出并增强了一系列诸如容器内资源动态感知、无停顿 GC（ZGC、Shenandoah）、原生的运维能力等等。这篇文章是 EDAS 团队的同学在服务客户的过程中，从云原生的角度将相关的功能进行整理和提炼而来。希望能和给大家一起认识一个新的 Java 形态。

47 技术 lddgo 分享于 2023-01-31

Java 凭借着自身活跃的开源社区和完善的生态优势，在过去的二十几年一直是最受欢迎的编程语言之一。步入云原生时代，蓬勃发展的云原生技术释放云计算红利，推动业务进行云原生化改造，加速企业数字化转型。 然而 Java 的云原生转型之路面临着巨大的挑战，Java 的运行机制和云原生特性存在着诸多矛盾。企业借助云原生技术进行深层次成本优化，资源成本管理被上升到前所未有的高度。公有云上资源按量收费，用户对资源用量十分敏感。在内存使用方面，基于 Java 虚拟机的执行机制使得任何 Java 程序都会有固定的基础内存开销，相比 C++/Golang 等原生语言，Java 应用占用的内存巨大，被称为“内存吞噬者”，因此 Java 应用上云更加昂贵。并且应用集成到云上之后系统复杂度增加，普通用户对云上 Java 应用内存没有清晰的认识，不知道如何为应用合理配置内存，出现 OOM 问题时也很难排障，遇到了许多问题。 为什么堆内存未超过 Xmx 却发生了 OOM？怎么理解操作系统和JVM的内存关系？为什么程序占用的内存比 Xmx 大不少，内存都用在哪儿了？为什么线上容器内的程序内存需求更大？

47 技术 lddgo 分享于 2023-01-31