Update Java Notes

Seazean · Seazean · commit 4e6a884707d9 · 2021-06-18T11:08:37.000+08:00
diff --git a/DB.md b/DB.md
@@ -9208,11 +9208,11 @@ bgsave指令工作原理：
 
 ![](https://gitee.com/seazean/images/raw/master/DB/Redis-bgsave工作原理.png)
 
-流程：当执行 bgsave 的时候，客户端发出 bgsave 指令给到 redis 服务器，服务器返回后台已经开始执行的信息给客户端，同时使用 fork函数 创建一个子进程，让这个子进程去执行save相关的操作，创建RDB文件保存起来，操作完以后把结果返回。
+流程：当执行 bgsave 的时候，客户端发出 bgsave 指令给到 redis 服务器，服务器返回后台已经开始执行的信息给客户端，同时使用 fork函数创建一个子进程，让子进程去执行 save 相关的操作，创建 RDB 文件保存起来，操作完以后把结果返回。
 
-bgsave分成两个过程：第一个是服务端收到指令直接告诉客户端开始执行；另外一个过程是一个子进程在完成后台的保存操作，操作完以后返回消息。**两个进程不相互影响**，所以在持久化期间Redis可以正常工作
+bgsave 分成两个过程：第一个是服务端收到指令直接告诉客户端开始执行；另外一个过程是一个子进程在完成后台的保存操作，操作完以后返回消息。**两个进程不相互影响**，所以在持久化期间 Redis 可以正常工作
 
-注意：bgsave命令是针对save阻塞问题做的优化，Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用
+注意：bgsave 命令是针对 save 阻塞问题做的优化，Redis 内部所有涉及到 RDB 操作都采用 bgsave 的方式，save 命令可以放弃使用
 
 
 
@@ -9248,7 +9248,7 @@ save 300 10	#300s内10个key发生变化就进行持久化
 * 对数据产生了影响
 * 不进行数据比对，比如 name 键存在，重新 set name seazean 也算一次变化
 
-save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
+save 配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
 
 RDB三种启动方式对比：
 
@@ -9289,7 +9289,7 @@ RDB三种启动方式对比：
   - RDB 是一个紧凑压缩的二进制文件，存储效率较高，但存储数据量较大时，存储效率较低
   - RDB 内部存储的是 redis 在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
   - RDB 恢复数据的速度要比 AOF 快很多，因为是快照，直接恢复
-  - 应用：服务器中每X小时执行 bgsave 备份，并将 RDB 文件拷贝到远程机器中，用于灾难恢复
+  - 应用：服务器中每 X 小时执行 bgsave 备份，并将 RDB 文件拷贝到远程机器中，用于灾难恢复
 
 * RDB缺点：
   - RDB 方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
@@ -9376,11 +9376,11 @@ AOF重写规则：
 
 - 非写入类的无效指令将被忽略，只保留最终数据的写入命令
 
-  如del key1、 hdel key2、srem key3、set key4 111、set key4 222等，select 指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
+  如 del key1、 hdel key2、srem key3、set key4 111、set key4 222等，select 指令虽然不更改数据，但是更改了数据的存储位置，此类命令同样需要记录
 
 - 对同一数据的多条写命令合并为一条命令
 
-  如lpushlist1 a、lpush list1 b、lpush list1 c 可以转化为：lpush list1 a b c。
+  如 lpushlist1 a、lpush list1 b、lpush list1 c 可以转化为：lpush list1 a b c。
 
   为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
 
@@ -9468,17 +9468,17 @@ AOF重写规则：
 
 - 数据呈现阶段有效性，建议使用 RDB 持久化方案
 
-  数据可以良好的做到阶段内无丢失，且恢复速度较快，阶段内数据恢复通常采用RDB方案
+  数据可以良好的做到阶段内无丢失，且恢复速度较快，阶段内数据恢复通常采用 RDB 方案
 
-  注意：利用 RDB 实现紧凑的数据持久化会使 Redis 降的很低
+  注意：利用 RDB 实现紧凑的数据持久化，存储数据量较大时，存储效率较低
 
 综合对比：
 
-- RDB与AOF的选择实际上是在做一种权衡，每种都有利有弊
-- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
-- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
-- 灾难恢复选用RDB
-- 双保险策略，同时开启 RDB和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量
+- RDB 与 AOF 的选择实际上是在做一种权衡，每种都有利有弊
+- 如不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用 AOF
+- 如能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用 RDB
+- 灾难恢复选用 RDB
+- 双保险策略，同时开启 RDB和 AOF，重启后，Redis 优先使用 AOF 来恢复数据，降低丢失数据的量
 
 
 
@@ -9488,7 +9488,7 @@ AOF重写规则：
 
 ### fork
 
-#### 函数介绍
+#### 介绍
 
 fork() 函数创建一个子进程，子进程与父进程几乎是完全相同的进程，系统先给子进程分配资源，然后把原来的进程的所有数据都复制到子进程中，只有少数值与父进程的值不同，相当于克隆了一个进程
 
@@ -9520,7 +9520,7 @@ fpid 的值在父子进程中不同：进程形成了链表，父进程的 fpid
 
 
 
-#### 函数使用
+#### 使用
 
 基本使用：
 
@@ -9596,11 +9596,11 @@ int main(void)
 
 
 
-#### 内存关系
+#### 内存
 
-fork()调用之后父子进程的内存关系
+fork() 调用之后父子进程的内存关系
 
-早期 Linux 的fork()实现时，就是全部复制，这种方法效率太低，而且造成了很大的内存浪费，现在 Linux 实现采用了两种方法来规避这种浪费：
+早期 Linux 的 fork() 实现时，就是全部复制，这种方法效率太低，而且造成了很大的内存浪费，现在 Linux 实现采用了两种方法来规避这种浪费：
 
 * 父子进程的代码段是相同的，所以代码段是没必要复制的，只需内核将代码段标记为只读，父子进程就共享此代码段。fork() 之后在进程创建代码段时，子进程的进程级页表项都指向和父进程相同的物理页帧
 
diff --git a/Java.md b/Java.md
@@ -8759,9 +8759,8 @@ epoll 的特点：
 
 * 硬中断：如网络传输中，数据到达网卡后，网卡经过一系列操作后发起硬件中断
 * 软中断：如程序运行过程中本身产生的一些中断
-  - 如进行系
   - 发起 `0X80` 中断
-  - 如程序执行碰到除 0 异常
+  - 程序执行碰到除 0 异常
 
 系统调用 system_call 函数所对应的中断指令编号是 0X80（十进制是8×16=128），而该指令编号对应的就是系统调用程序的入口，所以称系统调用为 80 中断
 
@@ -8801,13 +8800,13 @@ DMA (Direct Memory Access) ：直接存储器访问，让外部设备不通过 C
 
 <img src="https://gitee.com/seazean/images/raw/master/Java/IO-DMA.png" style="zoom: 50%;" />
 
-DMA 方式是一种完全由硬件进行组信息传送的控制方式，通常系统总线由 CPU 管理，在 DMA 方式中，CPU 把总线让出来由 DMA 控制器接管，用来控制传送的字节数、判断 DMA 是否结束、以及发出DMA结束信号，所以 DMA 控制器必须有以下功能：
+DMA 方式是一种完全由硬件进行组信息传送的控制方式，通常系统总线由 CPU 管理，在 DMA 方式中，CPU 的主存控制信号被禁止使用，CPU 把总线（地址总线、数据总线、控制总线）让出来由 DMA 控制器接管，用来控制传送的字节数、判断 DMA 是否结束、以及发出 DMA 结束信号，所以 DMA 控制器必须有以下功能：
 
-* 能向 CPU 发出系统保持（HOLD）信号，提出总线接管请求
-* 当 CPU 发出允许接管信号后，负责对总线的控制，进入 DMA 方式
-* 能对存储器寻址及能修改地址指针，实现对内存的读写
-* 能决定本次 DMA 传送的字节数，判断 DMA 传送是否结束
-* 发出 DMA 结束信号，使 CPU 恢复正常工作状态（中断）
+* 接受外设发出的 DMA 请求，并向 CPU 发出总线接管请求
+* 当 CPU 发出允许接管信号后，进入 DMA 操作周期
+* 确定传送数据的主存单元地址及长度，并自动修改主存地址计数和传送长度计数
+* 规定数据在主存和外设间的传送方向，发出读写等控制信号，执行数据传送操作
+* 判断 DMA 传送是否结束，发出 DMA 结束信号，使 CPU 恢复正常工作状态（中断）
 
 
 
diff --git a/Tool.md b/Tool.md
@@ -4055,7 +4055,7 @@ Docker官方的Docker hub（https://hub.docker.com）是一个用于管理公共
 
 
 
-## 对比虚拟机
+## 虚拟机
 
 容器：
 

Original file line number	Diff line number	Diff line change
`@@ -4055,7 +4055,7 @@ Docker官方的Docker hub（https://hub.docker.com）是一个用于管理公共`
`4055`	`4055`
`4056`	`4056`
`4057`	`4057`
`4058`		`-## 对比虚拟机`
	`4058`	`+## 虚拟机`
`4059`	`4059`
`4060`	`4060`	`容器：`
`4061`	`4061`