Rust 的 Ownership 感觉仍然很复杂，但 Rust 官方文档 The Rust Programming Language - Understanding Ownership 所费篇幅似乎并不多。下面就阅读该文档并记录下来对 Rust Ownership 的理解，相信官方的文档会表述的比准确而清晰。
本文中对 Ownership, Move, Reference, Dereference, Mutable, Immutable, Borrow, Owner, Stack, Heap, Scope 等词不进行翻译，以免走样。同时在阅读过程中不进行过度的联想，不与 C/C++ 的引用, 指针, 指针的指针进行关联，力求做一个完全不会 C/C++ 的 Rust 初学者。
Ownership 是 Rust 独一无二的特性。内存管理一般是两种，显式分配与释放和 GC, 这两种的弊端无需多说。Rust 另辟溪径，用 Owership 的一系列的规则来指导怎么管理内存，编译期保证程序运行期的内存安全性，不影响运行时性能。学习 Rust 的过程中需要很长时间去适应 Ownership, 从 Rust 开发者(Rustacean) 的经验来说是：随着对 Ownership 的掌握，越来轻松自然的写出安全高效的代码(希望如此)。 Read More- 试手了一下 Rust, 发现止今所学知识尚浅，不少情况处理起来很是茫然，比如经常得到的值是 Result 或 Option, 有时候要 .unwrap(), 有时得后面加个问号，或 .await。还有从自定义函数里返回一个引用都不容易，到处是 move, borrow, owner, lifetime 之类的错误信息。所以说，快充五分钟还真不敢上路，继续学习 Rust 的 Result, 说起它又必须与 Rust 的错误处理联系起来。
编程语言在处理错误无外乎就两种哲学- 得到正确的结果或触发异常，异常不就地处理则向外传播
- 总是能得到一个结果，于结果中获知是否有异常，如 Option<T>, Result<T, E>
第二种方式，在 shell 或 C++ 很常见，比如 shell 下每调用一个命令都有返回数值, 即 $?, 0 为正常，非 0 为有错误; C++ 的 GetLastError() 也是一样的意思。
现在所学的 Rust 在处理结果和错误时，采用了第二种方式，不过使用上 Rust 的模式匹配处理起 Option<T>, Result<T, E> 倒也不难，而且 Option<T> 和 Result<T, E> 这样的返回结果还用来向上传播异常，出错时还能追踪到异常栈。 Read More 
出现此错误的大致环境如下- SpringBoot 2.7.17, SpringWeb 项目，所引用入的 spring-webmvc-5.3.30, spring 6 已解决
- JDK 1.8 或 JDK 17
- 依赖了 jackson-dataformat-xml:2.12.6 和 jackson-dataformat-cbor:2.12.6, 它会在 RestTemplate 加上 application/xml, application/cbor 等 Accept 类型
- 代码中用 RestTemplate 调用此应用的 Endpoint, 未设置任何头
后面会详细列出能重现此问题的 pom.xml 配置及 Java 代码
在执行restTemplate.getForEntity("http://localhost:8080/test2", String.class)
时出现如下错误 Read More引用与解除引用
觉得还是有必要继续深入学习一下 Rust 再练手，毕竟仍然看到 & 和 * 符号还有些恍惚，大概就是 C/C++ 里的取地址和取值操作吧，实际上也确实类似。只是叫法略有不同, 还有就是在 C/C++ 多用了指针的概念。
在 C/C++ 中，&：称作 Address-of Operator, 在 Rust 中称作 Reference Operator, 而*在 C/C++ 和 Rust 中都叫做 Dereference Operator。以前学 C/C++ 经常被一系列的 &, * 打晕了头，如今参考了它们的英文名称立刻变得清晰了起来。
就像当初看汇编各种寻址方式弄得头都大了，其实也就是依照约定。 Read More
有好长一段时间没使用 Redis 了，之前用的都是 AWS 上的 Elastic Cache 的 Redis, 那时候还是用的版本还是 4 和 5。在新的项目由于觉得 Elastic Cache Redis 太贵而未曾使用，在去年的 AWS re:Invent 2023 上发布了 Elastic Cache Serverless，对于非长时间大数据的缓存可以考虑使用。而且还可以使用 Redis 的功能对服务进行解耦合，或作为一致性的协调中心。
此文是作为正式研究使用 Redis Stream (Redis 5.0 新特性) 的一个铺垫，探索在 Redis Stream 之前，可以何种方式把 Redis 当成一个消息队列，后面将会具体讲到如何用 Redis Stream 作为一个支持消费者组，能确认消息的更为完备的消息队列。
如以下几种方式- Pub/Sub 订阅模式
- 基于 List 的 LPUSH + BRPOP 的实现
- SortedSet, 使用消息 Score 排序功能进行消费
Pub/Sub 订阅模式
它就像 AWS 的 SNS 一样，只有在线的订阅者才能收到消息，每个消费者会收到相同的消息。相关的 Redis 命令是 *sub*, *pub*, 参考 Redis Command group Pub/Sub。订阅的时候可以直接指定 Channel 名称，或用模式匹配，还可关注某些 Key 的事件。 Read More- 再继续快速学习一下 Rust 的以下几个知识点，就可以开始着手做点小工具了
- 基本数据类型
- 复合数据类型
- 基本的流程控制
元组
元组和 Python 的元组用法类似，Immutable, 可混合类型1let tup1 = (10, 7.2, 'a'); 2let tup2 = (100, ); // 一个元素时，和 Python 一样，后面附加逗号，否则视括号可选 3let tup3: (i8, f32, boo) = (-10, 7.7, false); // 类型要一一对应 4let tup4: () = (); // 声明一个空元组，元组是不可变的，所以没什么意义 5 6let (x, y, z) = tup1; // 元组的拆解 7 8println!("{}", tup1.0); // 访问用 .index 方式访问数组
数组类型中的元素类型相同，表示为 [T; n], T 为类型，n 为元素个数 Read More - 学了不少编程语言，多数是离不开垃圾回收的，要么像 C++ 仍然是过于复杂，对于通用，编译型编程语言 Rust 是个不错的选择, Rust 不需要垃圾回收器。Rust 是由 Mozilla 主导开发的，设计准则为 "安全，并发，实用", 支持函数式，并发式，过程式以及面向对象的编程风格。Rust 能达到与 C++ 接近的性能，它又是编译型语言，编译出来二进制文件执行时不再依赖于运行时。Rust 有自带的 Cargo 作为依赖管理与构建工具，免除了关键工具的选择综合症。AWS 在今年也推出了 Rust 的 AWS SDK, 所以学习 Rust 的过程中也打算使用它来操作 AWS 的资源。
Rust 的 Hello World
在 macOS 下的安装$ brew install rust
或$ curl https://sh.rustup.rs | sh # 安装 $ rustc --version # 查看版本 $ rustup update # 更新 $ rustup self uninstall # 卸载
当前 Rust 版本为 1.74.0, 安装后有 rustc, rustdoc, rust-gdb, rust-lldb, cargo 等相关命令 Read More 
本篇同样是阅读《100 Java Mistakes and How to Avoid Them》的一则笔记，只是火力全集中在 StackOverflowError 这个单一主题之上, 且主要与递归及尾递归优化相关。一提到 StackOverflow, 恐怕首先是想到那个代码搬运源网站 stackoverflow.com，其次才是代码执行过程中的 StackOverflowError 错误。
什么是 StackOverflow, 准确来说是指线程的栈内存不足，无法在栈中分配新的内存(或创建新的栈帧)。我们通常会把它与方法调用关联起来，因为一次方法调用会创建一个新的栈帧，分配在栈上的局部变量(包括基本类型与对象引用)，和栈帧都要占用线程栈内存。而我们平时所说的方法调用栈，或出现异常时打印出的异常栈都是一个概念。
StackOverflowError 一般出现在方法调用太深(方法调方法)，手动编写的方法调用一般不容易达到这个限制，所以它与递归调用关系最为密切，递归调用次数太多或甚至没有出口条件无限递归; 也可能是经过一番递归调用后，再正常调用后续方法时出现 StackOverflowError(因为前面的递归调用资源消耗的差不多)
何谓递归调用，简单的说就是方法自己调用自己，从而实现循环的效果，或使代码更精练，例如经典排序中的快速和归并排序就要用到递归。但循环与递归又有本质上的区别，循环不增加调用深度；递归却不同，递归分递进与回归两个过程，递进调用时每次调用前都需通过压栈来保留现场，逆向回归时再逐级恢复现场，保留现场的过程就要从线程栈中分配内存空间; 死循环可能不会造成程序异常，但死(无限)递归必定出现 StackOverflowError。 Read More
不觉一晃还是在五年前记录过一篇 Dockerfile 中命令的两种书写方式的区别，其中提到过 Dockerfile 中可选择用 ENTRYPOINT 或 CMD 来启动进程，并且在 ENTRYPOINT 和 CMD 都支持 exec, shell 和增强型 shell 方式。如果同时有 ENTRYPOINT 和 CMD(或 docker 运行时的 CMD), 则 CMD 将为 ENTRYPOINT 提供参数。
在原来那篇文中认为 shell 无法接收到 docker stop 或 docker -s SIGTERM 发来的信号，也许是随着 Docker 版本的变迁，Docker 变得越发聪明了起来，无论何种格式的 ENTRYPOINT, 都能够收到 SIGTERM 信号，比如在 Java 的 ShutdownHook 能捕捉到该信号，得以在进程停止之前作必要的清理工作。
进行本文相关研究的主因是部署在 ECS(Fargate) 中的 Java Web 服务，Task 总是因为 OutOfMemoryError 被杀掉，而在应用程序日志中却见不着半点线索说 JVM 的 OutOfMemoryError，即使后来给 Fargate 配上了 EFS, 加了+XX:+HeapDumpOnOutOfMemoryError XX:HeapDumpPath=/efsJVM参数，在任务被 kill 时在 /efs 上从来就都没生成过内存映像文件。最后发现是因为 JVM 的 -Xmx 配置太高，留给 Fargate 容器的太少的缘故。 Read More