（目标最大停顿 200ms）

在 Java 应用的早期阶段（Java 6 之前），主流的垃圾回收器是和。：吞吐量优先，但会触发的 Full GC，停顿时间随堆增大而显著增加。CMS：以低延迟为目标，回收阶段与应用线程并发执行，但容易产生内存碎片，且在 JDK 9 已被废弃。随着大内存（>8GB）堆的普及以及云原生场景对可预测停顿时间停顿时间可预测（软实时）内存整理（无碎片）大堆友好的新型 GC这就是 G1 诞生的背景。空间连续

我在自己写脚本的过程中遇到很多坑，我本身是学java的，python接触不多，遇到了很多问题，但是今天写的时候，有些bug已经想不起来了。遇到的最难解决的两个问题就是：1、跟着其他博主博客写代码，博主博客不写清楚包的版本号；2、我本地可能是工具版本的问题，在下载工具包时，总是会报包不存在的问题，根本原因是我本地的brew有问题、pip命令也有问题(使用了/Users/xxx/MyMCP/venv/

这就是java虽然是解释执行，但相比编译执行的运行速度不差多少，就是因为JVM有JIT机制和解释执行两种方式配合执行，JIT适合热点代码，执行快；解释执行适合冷代码，启动快，两者相互搭配。且对于Java项目来说，当服务器持续处理请求时，JIT会持续优化，当热点代码被JIT 编译后，执行速度很快。第一步：把.java源文件编译为.class字节码文件(也叫jvm指令集)，，这是第一次编译，生成的这个

undo log存放的是每行数据的每个版本节点，版本之间使用DB_ROLL_PTR串联起来，DB_ROLL_PTR中存储的是每次生成的undo log在undo tablespace中的偏移量(地址)。Undo 写入后，InnoDB 得到该 Undo 记录的地址，例如：Undo Addr = undo_page_50:offset_512。：崩溃恢复不依赖"永久保留所有 Undo"，而是依赖"Re

1、实现了AutoCloseable接口的类在使用过程中要关闭资源，避免资源泄露，如HttpClient、HttpResponse对象。// 创建 HTTP GET 请求// 配置请求参数.setSocketTimeout(1000) // 设置 socket 超时时间.setConnectTimeout(1000) // 设置连接超时时间.setConnectionRequestTimeout(

我在自己写脚本的过程中遇到很多坑，我本身是学java的，python接触不多，遇到了很多问题，但是今天写的时候，有些bug已经想不起来了。遇到的最难解决的两个问题就是：1、跟着其他博主博客写代码，博主博客不写清楚包的版本号；2、我本地可能是工具版本的问题，在下载工具包时，总是会报包不存在的问题，根本原因是我本地的brew有问题、pip命令也有问题(使用了/Users/xxx/MyMCP/venv/

1、实现了AutoCloseable接口的类在使用过程中要关闭资源，避免资源泄露，如HttpClient、HttpResponse对象。// 创建 HTTP GET 请求// 配置请求参数.setSocketTimeout(1000) // 设置 socket 超时时间.setConnectTimeout(1000) // 设置连接超时时间.setConnectionRequestTimeout(

CountDownLatch 是 JUC（java.util.concurrent）包里 “一次性门闩” 同步器，一个/多个线程 在门闩上 await() 等待；另一个/另一些线程 执行完业务后 countDown() 把计数减到 0，门闩瞬间打开，所有等待线程同时通过，且。-让数千线程 同时 开始发请求（先 await，再一起 countDown）。-微服务启动前必须 等待 DB、Redis、M

CountDownLatch 是 JUC（java.util.concurrent）包里 “一次性门闩” 同步器，一个/多个线程 在门闩上 await() 等待；另一个/另一些线程 执行完业务后 countDown() 把计数减到 0，门闩瞬间打开，所有等待线程同时通过，且。-让数千线程 同时 开始发请求（先 await，再一起 countDown）。-微服务启动前必须 等待 DB、Redis、M