Merge pull request #2114 from JacketFu/main

Update jvm-garbage-collection.md

docs/database/mysql/mysql-logs.md

@@ -114,6 +114,47 @@ tag:
 
 ![](https://oss.javaguide.cn/github/javaguide/12.png)
 
+注意从 MySQL 8.0.30 开始，日志文件组有了些许变化：
+
+> The innodb_redo_log_capacity variable supersedes the innodb_log_files_in_group and innodb_log_file_size variables, which are deprecated. When the innodb_redo_log_capacity setting is defined, the innodb_log_files_in_group and innodb_log_file_size settings are ignored; otherwise, these settings are used to compute the innodb_redo_log_capacity setting (innodb_log_files_in_group * innodb_log_file_size = innodb_redo_log_capacity). If none of those variables are set, redo log capacity is set to the innodb_redo_log_capacity default value, which is 104857600 bytes (100MB). The maximum redo log capacity is 128GB.
+
+> Redo log files reside in the #innodb_redo directory in the data directory unless a different directory was specified by the innodb_log_group_home_dir variable. If innodb_log_group_home_dir was defined, the redo log files reside in the #innodb_redo directory in that directory. There are two types of redo log files, ordinary and spare. Ordinary redo log files are those being used. Spare redo log files are those waiting to be used. InnoDB tries to maintain 32 redo log files in total, with each file equal in size to 1/32 * innodb_redo_log_capacity; however, file sizes may differ for a time after modifying the innodb_redo_log_capacity setting.
+
+意思是在 MySQL 8.0.30 之前可以通过 `innodb_log_files_in_group` 和 `innodb_log_file_size` 配置日志文件组的文件数和文件大小，但在 MySQL 8.0.30 及之后的版本中，这两个变量已被废弃，即使被指定也是用来计算 `innodb_redo_log_capacity` 的值。而日志文件组的文件数则固定为32，文件大小则为 `innodb_redo_log_capacity / 32` 。
+
+关于这一点变化，我们可以验证一下。
+
+首先创建一个配置文件，里面配置一下 `innodb_log_files_in_group` 和 `innodb_log_file_size` 的值：
+
+```properties
+[mysqld]
+innodb_log_file_size = 10485760
+innodb_log_files_in_group = 64
+```
+
+docker启动一个 MySQL 8.0.32 的容器：
+
+```bash
+docker run -d -p 3312:3309 -e MYSQL_ROOT_PASSWORD=your-password -v /path/to/your/conf:/etc/mysql/conf.d --name
+MySQL830 mysql:8.0.32
+```
+
+现在我们来看一下启动日志：
+
+```
+2023-08-03T02:05:11.720357Z 0 [Warning] [MY-013907] [InnoDB] Deprecated configuration parameters innodb_log_file_size and/or innodb_log_files_in_group have been used to compute innodb_redo_log_capacity=671088640. Please use innodb_redo_log_capacity instead.
+```
+
+这里也表明了 `innodb_log_files_in_group` 和 `innodb_log_file_size` 这两个变量是用来计算 `innodb_redo_log_capacity` ，且已经被废弃。
+
+我们再看下日志文件组的文件数是多少：
+
+![](images/redo-log.png)
+
+可以看到刚好是32个，并且每个日志文件的大小是 `671088640 / 32 = 20971520`
+
+所以在使用 MySQL 8.0.30 及之后的版本时，推荐使用 `innodb_redo_log_capacity` 变量配置日志文件组
+
 ### redo log 小结
 
 相信大家都知道 `redo log` 的作用和它的刷盘时机、存储形式。
@@ -202,7 +243,7 @@ tag:
 - **上图的 write，是指把日志写入到文件系统的 page cache，并没有把数据持久化到磁盘，所以速度比较快**
 - **上图的 fsync，才是将数据持久化到磁盘的操作**
 
-`write`和`fsync`的时机，可以由参数`sync_binlog`控制，默认是`0`。
+`write`和`fsync`的时机，可以由参数`sync_binlog`控制，默认是`1`。
 
 为`0`的时候，表示每次提交事务都只`write`，由系统自行判断什么时候执行`fsync`。
 

docs/java/jvm/class-file-structure.md

@@ -60,9 +60,7 @@ ClassFile {
     u4             magic; //Class 文件的标志
 ```
 
-每个 Class 文件的头 4 个字节称为魔数（Magic Number）,它的唯一作用是**确定这个文件是否为一个能被虚拟机接收的 Class 文件**。
-
-程序设计者很多时候都喜欢用一些特殊的数字表示固定的文件类型或者其它特殊的含义。
+每个 Class 文件的头 4 个字节称为魔数（Magic Number）,它的唯一作用是**确定这个文件是否为一个能被虚拟机接收的 Class 文件**。Java规范规定魔数为固定值：0xCAFEBABE。如果读取的文件不是以这个魔数开头，Java虚拟机将拒绝加载它。
 
 ### Class 文件版本号（Minor&Major Version）
 

docs/java/jvm/jvm-garbage-collection.md

@@ -107,7 +107,10 @@ public class GCTest {
 
 大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。
 
-大对象直接进入老年代主要是为了避免为大对象分配内存时由于分配担保机制带来的复制而降低效率。
+大对象直接进入老年代的行为是由虚拟机动态决定的，它与具体使用的垃圾回收器和相关参数有关。大对象直接进入老年代是一种优化策略，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。
+
+* G1垃圾回收器会根据-XX:G1HeapRegionSize参数设置的堆区域大小和-XX:G1MixedGCLiveThresholdPercent参数设置的阈值，来决定哪些对象会直接进入老年代。
+* Parallel Scavenge垃圾回收器中，默认情况下，并没有一个固定的阈值(XX:ThresholdTolerance是动态调整的)来决定何时直接在老年代分配大对象。而是由虚拟机根据当前的堆内存情况和历史数据动态决定。
 
 ### 长期存活的对象将进入老年代
 
@@ -229,6 +232,8 @@ public class ReferenceCountingGc {
 - 方法区中类静态属性引用的对象
 - 方法区中常量引用的对象
 - 所有被同步锁持有的对象
+- JNI（Java Native Interface）引用的对象
+
 
 **对象可以被回收，就代表一定会被回收吗？**