最近同事说到 Java 的ParallelGCThreads 参数，我翻了下 jdk8 的代码，发现 ParallelGCThreads 的参数默认值如下： 如果 cpu 核心数目少于等于 8，则 GC 线程数量和 CPU 数一致 如果 cpu 核心数大于 8，则前 8 个核，每个核心对应一个 GC 线；其他核，每 8 个核对应 5 个 GC 线程 但是被提醒，发现即使在分配 4 核的容器上，GC 线程数也为 38。然后就想到应该和容器的资源限制有关—— jvm 可能无法觉察到当前容器的资源限制。 翻了下代码，发现最新版本的 java 是能感知容器的资源限制的，就按照jdk版本再翻了下代码。
站在 2023 年的今天，Service Mesh 早已不是一个新兴的概念， 回顾过去 6 年多的发展历程，Service Mesh 从一经推出就受到来自全世界的主流技术公司关注和追捧。 2016 年作为 Service Mesh 的元年，Buoyant 公司 CEO William Morgan 率先发布 Linkerd[1] ，成为业界首个 Service Mesh 项目，同年 Lyft 发布Envoy[2] ，成为第二个 Service Mesh 项目。 2017年，Google、IBM、Lyft 联手发布了 Istio[3]，它与 Linkerd / Envoy 等项目相比，它首次给大家增加了控制平面的概念，提供了强大的流量控制能力。经过多年的发展 Istio，已经逐步成为服务网格领域控制平面的事实标准。 2018年7月，Istio 1.0版本发布[4]，标志着其进入了可以生产可用的时代，逐渐也有越来越多的企业开始考虑和尝试将服务网格应用于生产中。 Istio 作为当前最流行的开源服务网格技术，它由控制平面和数据平面两部分构成。
阿里巴巴中间件陪伴大家又是一年了，春节即将到来，我们不禁回望，这一年我们留下了什么，又收获了什么。 翻阅着一篇又一篇的稿件，细数着往日的场景，2022年我们共发布了151篇文章，是各位读者的厚爱，让我们能持之以恒地与大家分享云原生和中间件的每一点变化。在这些内容中，我们看到了技术人员对精进自身的渴望，也看到了大家解决问题的思路，更能感受到大家对产品和技术的热情与真挚，以及遇到新开源项目时的兴奋与期待。因此，当我们按下「发布」时，希望能不负每一位开发者的等候。 我们选取部分内容，带大家重温过去一年的好文章。
现在，领导要响应集团提高代码质量的号召，需要提升单元测试的代码覆盖率。当然，我们不能让领导失望，那就加班加点地补充单元测试用例，努力提高单元测试的代码覆盖率。至于单元测试用例的有效性，我们大抵是不用关心的，因为我们只是面向指标编程。 我曾经阅读过一个Java服务项目，单元测试的代码覆盖率非常高，但是通篇没有一个依赖方法验证（Mockito.verify）、满纸仅存几个数据对象断言（Assert.assertNotNull）。我说，这些都是无效的单元测试用例，根本起不到测试代码BUG和回归验证代码的作用。后来，在一个月黑风高的夜里，一个新增的方法调用，引起了一场血雨腥风。 编写单元测试用例的目的，并不是为了追求单元测试代码覆盖率，而是为了利用单元测试验证回归代码——试图找出代码中潜藏着的BUG。所以，我们应该具备工匠精神、怀着一颗敬畏心，编写出有效的单元测试用例。在这篇文章里，作者通过日常的单元测试实践，系统地总结出一套避免编写无效单元测试用例的方法和原则。
可能大家谈到低代码想到更多的是低代码搭建页面的平台，内部不少也是此种，其实对于偏逻辑编排、服务 BaaS 能力的偏可视化方式其实也算低代码，旨在「通过少写代码，用更便捷的方式来实现原本需写代码的工作」。 说到低代码，喜欢的人特别喜欢，不喜欢的人很不喜欢，此外也有“假装”去喜欢的，也有喜欢得不明不白的，我现在对于低代码是有点儿喜欢的那种，不过只限于「在特定领域，实现需求的速度比熟练工程师写代码要快的场景」，这种场景下用起来真心会比较爽，可能也用得不爽的时候，但是这种不爽远小于他带来的效益减去原本敲代码的投入，也很值得将这类产品做到好用爱用。 其实低代码产品是比较难做成的，特别是大而全的那种，由于考虑因素过多，导致步调很慢，也很难做到很易用，导致一边投入很大，一边又急切上线落地使用，从而出现平台方觉得投入很苦，使用方觉得不太好用还需吃狗粮的矛盾，往往需经过忍耐很长时间才可「守得云开见月明」，不过很多都在没有见月明的时候就奄奄一息了。反而专门领域的比如说表单、表格、图表低代码搭建活的很不错。还有一些 BaaS 类单领域的活得也还可以，我个人更偏向「易用的可很轻快解决对应领域问题低代码产品
在 JDK 9 之前，Java 基本上平均每三年出一个版本。但是自从 2017 年 9 月分推出 JDK9 到现在，Java 开始了疯狂更新的模式，基本上保持了每年两个大版本的节奏。从 2017 年至今，已经发布了 十一个版本到了 JDK 19。其中包括了两个 LTS 版本（JDK11 与 JDK17）。除了版本更新节奏明显加快之外，JDK 也围绕着云原生场景的能力，推出并增强了一系列诸如容器内资源动态感知、无停顿 GC（ZGC、Shenandoah）、原生的运维能力等等。这篇文章是 EDAS 团队的同学在服务客户的过程中，从云原生的角度将相关的功能进行整理和提炼而来。希望能和给大家一起认识一个新的 Java 形态。
Java 凭借着自身活跃的开源社区和完善的生态优势，在过去的二十几年一直是最受欢迎的编程语言之一。步入云原生时代，蓬勃发展的云原生技术释放云计算红利，推动业务进行云原生化改造，加速企业数字化转型。 然而 Java 的云原生转型之路面临着巨大的挑战，Java 的运行机制和云原生特性存在着诸多矛盾。企业借助云原生技术进行深层次成本优化，资源成本管理被上升到前所未有的高度。公有云上资源按量收费，用户对资源用量十分敏感。在内存使用方面，基于 Java 虚拟机的执行机制使得任何 Java 程序都会有固定的基础内存开销，相比 C++/Golang 等原生语言，Java 应用占用的内存巨大，被称为“内存吞噬者”，因此 Java 应用上云更加昂贵。并且应用集成到云上之后系统复杂度增加，普通用户对云上 Java 应用内存没有清晰的认识，不知道如何为应用合理配置内存，出现 OOM 问题时也很难排障，遇到了许多问题。 为什么堆内存未超过 Xmx 却发生了 OOM？怎么理解操作系统和JVM的内存关系？为什么程序占用的内存比 Xmx 大不少，内存都用在哪儿了？为什么线上容器内的程序内存需求更大？
OLAP计算引擎是一架机器，而操作这架机器的是编程语言。使用者通过特定语言告诉计算引擎，需要读取哪些数据、以及需要进行什么样的计算。编程语言有很多种，任何人都可以设计出一门编程语言，然后设计对应的编译器做解析。编程语言从分类上来说，可以分为命令式，声明式。 命令式编程语言是我们最常见的编程语言，C/C++/Java等都是命令式编程语言，这类语言明确的告诉机器应该执行什么样的指令，留给编译器优化的空间很小了。 声明式编程描述程序应该获得什么结果，至于如何做到，并不关注细节。SQL就是一种声明式编程语言。例如SQL语句select count(1) from department where kpi =3.25，指明计算kpi=3.25的人数，但不会具体指定如何完成计算。这给后续的优化器留下了很大的操作空间，优化器可以根据SQL的需求和实际的数据做各种各样的探索，寻找到最佳的执行方式。
和众多传统行业一样，跨境贸易产业近年来也经历了数字化的转型创新，而首先参与进模式创新的地方主要集中于信息展示和业务撮合领域。本文将为大家分享阿里国际站在用户增长技术体系建设上的探索与实践。
