Java 24 也是一个过渡版本, 还是到下面两个链接中找相应的更新
IntelliJ IDEA 对 Java 22 Language level 描述是
- 23 - Markdown document comments
- 22(Preview) - Primitive types in patterns, implicitly declared classes, etc.
把上面第二个链接中的特性列出来
本文对上面用红点标记的特性重点关注
Read MoreJava 22 是一个过渡版本, 还是到下面两个链接中找相应的更新
IntelliJ IDEA 对 Java 22 Language level 描述是
- 22 - Unnamed variables and patterns
- 22(Preview) - Statements before super(), string templates (2nd preview), etc.
把上面第二个链接中的特性列出来
本文对上面用红点标记的特性重点关注
Read More迁移完所有的 WordPress 日志到 Hugo 之后, 终于有时间真正继承学习相关的新技术. Java 21 是于 2023 年 9 月份释放出来的 LTS 版本, 目前主要在用该版. Java 25 LTS 版本已发布, 按正常节奏应该要切换到该版本.
随着 AI 在编程界的花式表演, 所宣传的似乎就是要扑灭他人的学习热情, 编程方面越小白越好, 只要能写好小作文就行了. AI 当然还是要用, 但我对以往多少年传统的学习方式并不感到白花了心血. 告诉 AI 的一个课题 AI 确实能写出一篇漂亮, 规整的博客文章, 但其中有没有胡说八道, 只有试了才知道, 即使生成的文章无误, 也必须实践一遍才有更多更深的斩获.
如果没有相关的技术储备, 每次与 AI 互动的时候都要告诉它尽量用 Java 21 新特性, 因为新引入的特性基本能实现得更简洁, 高效, 估计 AI 才不那么在乎这些, 写出适于人阅读的代码恐怕不是 AI 的首要关注.
还是老办法, 关于 Java 某一版本新特性从两个链接出发
Read More篇首说明: 本文十分冗长, 语言组织混乱, 如果觉得 TLDR, 就直接跳到 关于虚拟线程的总结 部分看要点, 若对总结上中的某些要素点仍有兴趣的话请倒查本文中其他部分的内容. 个人对 Java 虚拟线程的主动研究是为了在项目中更有效的使用它.
关于线程的概要
Java 21 于两年前 2023 年 9 月份放出，它是一个 LTS(long term support) 版本，个人基本就是把 LTS 当作能在正式项目中使用的版本。 Java 21 有几个增进编程体验的特性，像 Sequenced Collections, Record Patterns, 和 Pattern Matching for switch, 而对于性能改进的， 也是 Java 21 最具代表的特性无疑就是 Virtual Threads -- 虚拟线程。本文单列出它来，着重感受一下虚拟线程是什么，以及我们应该如何使用它。
其实在之前的 Java 19, 20 新特性学习 就有一定的笔墨介绍了于 Java 19 引入， Java 20 中尚处于第二次预览的虚拟线程。于其中大致体验了在一台 36 G 物理内存，默认堆内存为 9 G 的情况下， 创建 9000 个线程没问题，但要创建 10000 个线程就 OutOfMemoryError 了。而相同的环境下创建一百万个虚拟线程都没问题，没在继续往下试探了。
其实这种比较是没有意义的, Java 线程对应到平台线程的, 每个线程要至少实实在在的 2M 栈空间, 而一百万个虚拟线程相当于是创建了一百万个 Java 对象而已, 更像是相应数量的 Task, 实际运行时才由载体线程去调度执行 - (注: 后面所提到的载体线程和平台线程是同一个概念).
重新回顾一下何谓虚拟线程，Java 的虚拟线程实现是来自于 Project Loom 项目。与此相关的概念有线程，协程，以及纤程(Fiber)，而虚拟线程对应的应该是纤程。
- 线程是操作系统最小的调度单位，每个线程有独立较大的栈空间(比如 2M)，内核调度，切换开销大，可有效使用 CPU 多核
- 协程在单个线程内执行，共享线程栈空间或独立小空间，用户态调度，切换开销极小，但无法使用多核
- 纤程，介于线程与协程之间，很小的独立栈，用户态调度，切换开销较小。结合线程池，纤程可在线程间转移，这时岂不是要经内核态调度吗？
写了几天 Rust 之后，不光被它的 Ownership, Lifetime 折磨的死去活来，还碰上个奇怪的错误处理方式。如果让程序员在 Java, C/C++, Python, Ruby, Scala, Go，甚至是 Lisp 语言之间换着干活，那还都不是难事，但是拉个人去弄 Rust 就会要人命了。
有垃圾回收的语言基本就是想怎么写都成，程序运行时也不会出太大的事，当然性能是个妥协; 像 C/C++ 自己管理内存的语言写出来的程序通过编译也容易，只是执行时很可能会有内存泄漏或地址越界。而选择号称性能与安全兼备的 Rust 语言的话，按照正常思维逻辑写出来的代码能通过编译就是最幸福的事。碰到关于 Ownership, Lifetime 之类的编译问题很多时候当前的 AI 也无解。
所以现在还能用 Java, Python, C# 等写代码是个幸福的事，这种时光应该好好的珍惜。换个角度来想，如果能掌握 Rust 那还怕别的语言吗？
就算能侥幸的应付 Ownership, Lifetime 的问题，Rust 错误处理方式也会让人抓狂，起初大量的用 unwrap() 忽略错误，用多了也会觉得不是一回事。
主流的语言都是采纳 try/catch 方式处理异常方式，异常在栈中向上传播，想在哪一层捕获异常都行，所以才可能在某处集中的处理异常，也让程序结果返回与异常处理得已分离。
有一个视频 什么是正确的错误处理方法【让编程再次伟大#21】介绍了各种编程语言错误处理方式的历史发展，视频博主十分推崇 Rust 的结果错误放 Result 的方式，觉得像 try/catch 那种能够实现关注点分离的方式是便宜了程序员，只有返回 Result<T, E> 的方式才能强制程序员步步小心。那何不让 try/catch 全部抛出 Checked 异常，然而事实是 Spring 框架把许多 Checked 异常转换成了 Unchecked 异常，能程序员处理更方便，且能集中处理异常。 Read More- AWS 在 2025-11-14 日发布了 AWS Lambda adds support for Rust, 即 AWS 正式支持用 Rust 写 Lambda 了, 回顾到之前 AWS 为 Rust 提供 SDK 是两年前的 2023-11-27: AWS SDK for Rust is now generally available.
日常中总有几个编程语言是要去掌握的, 像基本的脚本 Bash, 网页用的 JavaScript, 大项目用的 Java, AI 时代的 Python, 再就是仿佛 Rust 也是绕不过的. 之前有学过 Rust, 到现在忘差不多了, 又看到 Tauri, AWS Lambda 对 Rust 的大力支持，有必要放 Rust 提到与 Python, Java 一样的地位来看待。尽管学习起来比 C/C++ 还陡峭，像 解引用, Either(Result, Error), Unwrap, Borrow, Move, Ownership 等概念及规则需慢慢去熟悉。
从 AWS 控制台看看 Lambda 是怎么对 Rust 提供支持的，创建函数时，Runtime 中可以选择
Amazon Linux 2023
OS-only runtime for Go, Rust, C++, customAmazon Linux 2
OS-only runtime for Go, Rust, C++, custom
OS 方面当然是要选择 Amazon Linux 2023 优于 Amazon Linux 2。选择 Amazon Linux 2023 或 Amazon Linux 2 时最后还有一个 custom，也就是说可以自义的定义自己的 Lambda 运行时，可选择任何语言，只要符合 AWS Lambda 调用的接口规范 Using the Lambda runtime API for custom runtimes 即可。不过完全定义吗，还挺罗嗦的，用官方直接支持的语言就容易多了。 Read More 
自从 Terraform resource "aws_iam_role" 不推荐使用 "inline_policy" 和 "managed_policy_arns" 以后，就尝试了用 "aws_iam_policy_attachment" 来为 iam role 指定 AWS 内置和自定义的 IAM policy。因为在官方文档 aws_iam_role 中最先看到的就是 aws_iam_policy_attachment, 其实仔细阅读该文档的话，建议是- 用 "aws_iam_role_policy" 来代替 "inline_policy"
- 用 "aws_iam_role_policy_attachment" 来代替 "managed_policy_arns"
然后在项目中为避免 inline_policy 和 managed_policy_arns 的警告而选择了通用的 aws_iam_policy_attachment, 同时原来也用的 "aws_iam_policy"，而非 "aws_iam_role_policy。 所以才撞入到以前一直用 aws_iam_role(inline_policy, managed_policy_arns) + aws_iam_policy 就没出过问题。 Read More
平时随意用 Python 写的用了就丢的小工具当然没必要写什么单元测试，如果是一个要反复打磨的工具，项目，单元测试就必须重视起来了。因为简单思路写出来的代码将要应对各种未知情形，加之想要大肆的重构，有了足够的测试用例才能安心。
任何语言白盒的单元测试首先面对的就是 Mock, 不光是应对有副作用的操作，最好是隔离所有不在当前所见到的代码的任何调用，其实像print这种有副作用的代码一般是能容忍的，可能也是为何很多测试框架默认会把控制台的输出关掉。
在 Python 中，一般基本的东西自己都有，Mock 就直接用 unittest.mock，可应用于所有的单元测试框架中，如 unittest, pytest。另有一块对 uniitest.mock 的简单封装，专为 pytest 提供方便的 pytest-mock。今天先了解 unittest.mock 的使用，它的官方文档是 unittest.mock -- mock object library。 Read More