本想用一篇日志记录下在 Docker 容器中使用 Java 调用 C++ 动态库时，当 C++ Crash 时如何自动生成 core dump, 不想分成了至少三篇来完成这一研究。 可以回顾一下前两篇日志
本文是基于第二篇进一步推进，继续探索如何在 Docker 容器中 Java 调用 C++ 动态库时的 core dump 如何生成。首先测试的平台依然是 AWS EC2 实例， OS 为 Amazon Linux 2023, Docker 版本为 25.0.14。为叙事方便，本文所用代码与上篇一样，但还是重复一遍，省却了连接跳转。
Read More在 Java 应用程序通过 JNA 调用 C++ 动态库时，C++ 代码运行在与 Java 同一进程中，当 C++ 代码 Crash 的时候，将会导致整个 Java 应用程序崩溃。 对于一个 Web 应用，这不是我们期望的结果，由于某一个请求输入的数据导致 C++ 代码崩溃了当前 Java 进程，从而造成该 Web 服务已接受到的所有请求全部失败， 这是非常糟糕的用户体验。如果是 Java 代码本身的异常我们可用 try/catch 进行保护，影响只限制在当前请求。如果是 C++ 代码崩溃的话，Java 应用程序无法捕获到这个异常，以致于整个 Java 应用程序崩溃，甚至发生这种情况时连 hs_err.log 文件都来不及生成，更别说生成 HeapDump, 或 CoreDump 了。
如果是用原始 JNI 的方式来调用动态库，我们还能在 JNI 相关的 C++ 代码中捕获到异常，并抛给 Java 去处理。而用 JNA, 我们贪图了它的方便， 比如一个 Java 进程中同时加载同一接口的不同动态库版本(JNI 要同样的实现必须用自定义的 ClassLoader)，但在 C++ 代码崩溃时， Java 就显得无能为力了， 只能跟随着立即死亡, 并且在控制台下找不到关于 C++ 因何失败的线索。比如 C++ 中内存被多次释放，或地址越界访问破坏了内存数据等。
Read More
本文初衷是为了解决 Java 应用程序通过 JNA 调用 C++ 动态库时，C++ 代码运行崩溃导致整个 Java 应用程序崩溃而进行的研究。从一个 C++ 调用 C++ 写的动态库起步，记录它在什么情况下产生 core dump 文件，如何分析 core dump 文件等过程。可惜篇幅无法控制，不足以再加入 Java->JNA->C++ 动态库内容了，所以不得不单列此篇，并更名为 'C++ 调用 C++ 动态库时问题诊断'. 关于 Java JNA 到 C++ 的问题诊断只能另立一篇了。
下面我们来用 JNA 的方式来调用 C++ 动态库，演示当 C++ 代码崩溃时会发生什么，并试图找到好的诊断办法。以下演示在 Linux 下进行, 并且 Linux 发行版是 Amazon Linux 2023.
Read More- 之所以把 Java 19 与 20 放一块是因为这两个版本都没有一个算得上正式的特性。都是些预览的，孵化中的，唯有一个支持 Linux 下 RISC-V 指令集与我们基本无关。所以 Java 19 和 Java 20 纯粹的过度版本，根本不该被正式项目采用，在 IntelliJ IDEA 中也是标它们为 No new language features。在我们的实践中正式项目只用 LTS 版。
还是分别从 https://openjdk.org/projects/jdk/19/ 和 https://openjdk.org/projects/jdk/20/ 抓关注点
从上面可以挑几个稍加了解，详细的介绍应该在学习 Java 21 时。它们是 Read MoreJava 19 新特性 Java 20 新特性 - 有了 AI 是不是就用不着了解语言特性本身呢？用 Vibe Coding 难道就无所不能呢？如果是的话那些找工作的也就无需刷 LeetCode 了。试想 Vibe Coding 产生了成堆的代码，即使创建了 Pull Request, 也不是给人 Review 的，也只能由 AI 来 Review, 到头来就是 AI 与 AI 自己玩，有 Bug 也只有 AI 看得懂。以后的屎山代码是一车一车的来。
除了从 JDK 官方每个版本的 What's New in JDK 18 - New Features and Enhancements, 还可以看 OpenJDK JDK 18 列出的更简明的新特性。自 JDK 10 之后，每一版的新特性由链接 https://openjdk.org/projects/jdk/<version>/ 查看，如 JDK 10 新特性链接为 https://openjdk.org/projects/jdk/10/。
在 https://openjdk.org/projects/jdk/18/ 列出了 JDK 18 如下新特性- 400: UTF-8 by Default
- 408: Simple Web Server
- 413: Code Snippets in Java API Documentation
- 416: Reimplement Core Reflection with Method Handles
- 417: Vector API (Third Incubator)
- 418: Internet-Address Resolution SPI
- 419: Foreign Function & Memory API (Second Incubator)
- 420: Pattern Matching for switch (Second Preview)
- 421: Deprecate Finalization for Removal
找几个有代表性的着重加了学习 Read More - 昨天单列了 Java 17 新特性之密封类型, 继续刷 What's New in JDK 17 - New Features and Enhancements.
switch 模式匹配(预览)
在 Java 21 才正式放出，主动就是原来的 switch...case 语句可以写成表达式的方式，有返回值, 无需每个分支的 break, 并增加模式匹配功能，比如匹配类型，带约束子条件，匹配 record 的字段值等，这里不展开说明，待到详细了解 Java 21 新特性时再深入研究。新的 macOS 渲染管道
英文是 New macOS Rendering Pipeline, 主要是 Swing API 如果配置系统属性-Dsun.java2d.meta=true就可以用 Apple Metal 替代 OpenGL 加速渲染界面，很少写 Java Swing 桌面应用的略过。新的 API 可访问大图标
同样是在对 Swing 的改进，可用 FileSystemView 加载解析度的图标 Read More - 工作中所有项目都已升级到了当前的 LTS 版 Java 21, 眼看 Java 快要来到了下一个 LTS 版本 - Java 25，将于今年 9 月份发布。四年前记录过一篇 Java 10 ~ 16 一路向前冲(新特性一箩筐)，其中夹杂着孵化，预览中的以及正式的特性。现在继续跟随着 Java 16 之后版本的特性，主要讲述正式的，可直观体验到的特性，孵化与预览中的特性只会简单提及。
先还是看下 Java 的发布日期安排 Oracle Java SE Support Roadmap版本 发布日 原定支持至 延期支持至
也就是每两年(9月份)会有一个 LTS 版本，中间若干过度版本。在正式项目中尽可能只用 LTS 版本，因为 LTS 版更稳定，且有长期的补丁，不能项目进行中不得不在进行非 LTS 主版本升级。 Read More
Java 17(LTS) 2021/9 2026/9 2029/12
Java 18-20 2022/3 - 2023/3 2022/9 - 2023/9 N/A
Java 21(LTS) 2023/9 2028/9 2031/9
Java 22 2024/3 2024/9 N/A
Java 23 2024/9 2025/3 N/A
Java 24 2025/3 2025/9 N/A
Java 25(LTS) 2025/9 2030/9 2033/9 
使用 Tomcat 时应根据服务器的负载和客户端能接受的等待情可适当的调节 maxThreads, acceptCount, maxConnections 的值。这三个参数只有 maxThreads 是最容易理解，即 Tomcat 当前最大同时处理请求的数目，其他两个参数有些模糊。而搜索网络相关的解释发现一些相互矛盾的地方，本文将通过调整这几个值，实际体验它们对请求连接的影响。
在测试之前，先看看 Tomcat 官网的解释，你可能不信 AI 的胡说八道，官网仍然是最可信的。在关于 The HTTP Connector 一章中，找到它们三者之间的说明原文是Each incoming, non-asynchronous request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the
用 Google 翻译后 Read MoremaxThreadsattribute). If still more simultaneous requests are received, Tomcat will accept new connections until the current number of connections reachesmaxConnections. Connections are queued inside the server socket created by the Connector until a thread becomes available to process the connection. OncemaxConnectionshas been reached the operating system will queue further connections. The size of the operating system provided connection queue may be controlled by theacceptCountattribute. If the operating system queue fills, further connection requests may be refused or may time out.- 早先对 Java ArrayList 的扩容理解是在 new ArrayList() 时会默认建立一个内部容量为 16(这个数值还是错的，往后看) 大小的数组，然而插入数据容量不足时会扩容为原来的 1.5 倍，并用 System.arraycopy() 移动原来的数组到新的大数组中，所以为了频繁的内部扩容操作，在已知 ArrayList 将来大小的情况下，应该在创建 ArrayList 时指定大小，如 new ArrayList(1000)。那么是否指定初始容量对性能会有多大的影响仍缺乏感性的认识。
本文通过具体的测试主要掌握以下知识- new ArrayList() 默认容量大小(JDK 8 以前是 10, JDK 8 及以后为 0)
- ArrayList 何时进行扩容，以及每次扩容多少
- new ArrayList() 时是否指定初始容量值的性能对比
- 除了 ArrayList 自动扩容外，它会不会自动缩容呢？
new ArrayList() 的默认容量多少及增容策略
就像 JDK 8 的 HashMap 引入了红黑树改善性，随着 JDK 版本的升级 ArrayList 的内部实现也在演进。回到 JDK 7, 当我们不指定容量 new ArrayList() 创建一个对象时的实现是 Read More - Java 代码中如果显式的用
throw关键字抛出异常，那么在该分支中其后的语句不可到达，并且即使对于有返回值的函数也不必写return语句了。像下面的代码1private static int foo(int num) { 2 if (num == 0) { 3 throw new RuntimeException(""); 4 } else { 5 return num + 1; 6 } 7}
以上代码是合法的。要清洁代码的话，最后的return num + 1不必写在else条件中，这样写只是为了验证抛出异常后不必有返回值。
比如我们想对该代码进行重构，把throw语句抽取到一个方法中，以便于在该方法中集中处理错误信息，于是变成了 Read More