Update Java Notes

Seazean · Seazean · commit 3762c92afe08 · 2021-06-17T08:34:06.000+08:00
diff --git a/DB.md b/DB.md
@@ -10817,22 +10817,12 @@ sentinel 在通知阶段不断的去获取 master/slave 的信息，然后在各
 
 ## 缓存方案
 
-### 缓存本质
-
-弥补 CPU 的高算力和 IO 的慢读写之间巨大的鸿沟
-
-
-
-
-
-***
-
-
-
 ### 缓存模式
 
 #### 旁路缓存
 
+缓存本质：弥补 CPU 的高算力和 IO 的慢读写之间巨大的鸿沟
+
 旁路缓存模式 Cache Aside Pattern 是平时使用比较多的一个缓存读写模式，比较适合读请求比较多的场景
 
 Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 DB 的结果为准
@@ -10855,10 +10845,10 @@ Cache Aside Pattern 中服务端需要同时维系 DB 和 cache，并且是以 D
 缓存不一致的方法：
 
 * 数据库和缓存数据**强一致**场景 ：
-  * 更新DB时同样更新 cache，加一个锁来保证更新 cache 时不存在线程安全问题，这样可以增加命中率
+  * 更新 DB 时同样更新 cache，加一个锁来保证更新 cache 时不存在线程安全问题，这样可以增加命中率
   * 延迟双删：先淘汰缓存再写数据库，休眠1秒再次淘汰缓存，可以将1秒内造成的缓存脏数据再次删除
   * CDC 同步：通过 canal 订阅 MySQL binlog 的变更上报给 Kafka，系统监听 Kafka 消息触发缓存失效
-* 可以短暂地允许数据库和缓存数据**不一致**场景：更新DB的时候同样更新 cache，但是给缓存加一个比较短的过期时间，这样的话就可以保证即使数据不一致影响也比较小
+* 可以短暂地允许数据库和缓存数据**不一致**场景：更新 DB 的时候同样更新 cache，但是给缓存加一个比较短的过期时间，这样就可以保证即使数据不一致影响也比较小
 
 
 
@@ -10954,9 +10944,9 @@ Read-Through Pattern 也存在首次不命中的问题，采用缓存预热解
 
 #### 缓存雪崩
 
-场景：数据库服务器崩溃，一连串的问题会随之而来。系统平稳运行过程中，忽然数据库连接量激增，应用服务器无法及时处理请求，大量408，500错误页面出现，客户反复刷新页面获取数据，造成：数据库崩溃、应用服务器崩溃、重启应用服务器无效、Redis服务器崩溃、Redis集群崩溃、重启数据库后再次被瞬间流量放倒
+场景：数据库服务器崩溃，一连串的问题会随之而来。系统平稳运行过程中，忽然数据库连接量激增，应用服务器无法及时处理请求，大量408，500错误页面出现，客户反复刷新页面获取数据，造成数据库崩溃、应用服务器崩溃、重启应用服务器无效、Redis 服务器崩溃、Redis 集群崩溃、重启数据库后再次被瞬间流量放倒
 
-问题排查：在一个较短的时间内，缓存中较多的key集中过期，此周期内请求访问过期的数据，redis未命中，redis向数据库获取数据，数据库同时接收到大量的请求无法及时处理；Redis大量请求被积压，开始出现超时现象；数据库流量激增，数据库崩溃，重启后仍然面对缓存中无数据可用；Redis服务器资源被严重占用，Redis服务器崩溃；Redis集群呈现崩塌，集群瓦解；应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越多，应用服务器崩溃；应用服务器，redis，数据库全部重启，效果不理想
+问题排查：在一个较短的时间内，缓存中较多的 key 集中过期，此周期内请求访问过期的数据，Redis 未命中，Redis 向数据库获取数据，数据库同时接收到大量的请求无法及时处理；Redis 大量请求被积压，开始出现超时现象；数据库流量激增，数据库崩溃，重启后仍然面对缓存中无数据可用；Redis 服务器资源被严重占用，Redis 服务器崩溃；Redis 集群呈现崩塌，集群瓦解；应用服务器无法及时得到数据响应请求，来自客户端的请求数量越来越多，应用服务器崩溃；应用服务器，redis，数据库全部重启，效果不理想
 
 解决方案：
 
@@ -10966,7 +10956,7 @@ Read-Through Pattern 也存在首次不命中的问题，采用缓存预热解
 
   2. 构建**多级缓存**架构：Nginx 缓存 + redis 缓存 + ehcache 缓存
 
-  3. 检测 Mysql 严重耗时业务进行优化：对数据库的瓶颈排查：例如超时查询、耗时较高事务等
+  3. 检测 Mysql 严重耗时业务进行优化：对数据库的瓶颈排查，例如超时查询、耗时较高事务等
 
   4. 灾难预警机制：监控redis服务器性能指标，CPU占用、CPU使用率、内存容量、平均响应时间、线程数
 
@@ -10976,7 +10966,7 @@ Read-Through Pattern 也存在首次不命中的问题，采用缓存预热解
 
   1. LRU 与 LFU切换
 
-  2. 数据有效期策略调整：根据业务数据有效期进行分类错峰，A类90分钟，B类80分钟，C类70分钟，过期时间使用固定时间 + 随机值的形式，稀释集中到期的key的数量
+  2. 数据有效期策略调整：根据业务数据有效期进行分类错峰，A类90分钟，B类80分钟，C类70分钟，过期时间使用固定时间 + 随机值的形式，稀释集中到期的 key 的数量
 
   3. 超热数据使用永久key
 
@@ -10995,17 +10985,17 @@ Read-Through Pattern 也存在首次不命中的问题，采用缓存预热解
 
 #### 缓存击穿
 
-场景：系统平稳运行过程中，数据库连接量瞬间激增，Redis服务器无大量key过期，Redis内存平稳，无波动，Redis 服务器 CPU 正常，但是数据库崩溃
+场景：系统平稳运行过程中，数据库连接量瞬间激增，Redis 服务器无大量 key 过期，Redis 内存平稳，无波动，Redis 服务器 CPU 正常，但是数据库崩溃
 
 问题排查：
 
-1. Redis中某个key过期，该key访问量巨大
+1. Redis 中某个 key 过期，该 key 访问量巨大
 
 2. 多个数据请求从服务器直接压到 Redis 后，均未命中
 
-3. Redis在短时间内发起了大量对数据库中同一数据的访问
+3. Redis 在短时间内发起了大量对数据库中同一数据的访问
 
-简而言之两点：单个key高热数据，key过期
+简而言之两点：单个 key 高热数据，key 过期
 
 解决方案：
 
@@ -11048,9 +11038,9 @@ Read-Through Pattern 也存在首次不命中的问题，采用缓存预热解
 
 1. 缓存null：对查询结果为null的数据进行缓存 (长期使用，定期清理) ，设定短时限，例如30-60秒，最高5分钟
 
-2. 白名单策略：提前预热各种分类数据id对应的**bitmaps**，id作为bitmaps的offset，相当于设置了数据白名单。当加载正常数据时放行，加载异常数据时直接拦截（效率偏低），使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）
+2. 白名单策略：提前预热各种分类数据 id 对应的 **bitmaps**，id 作为 bitmaps 的 offset，相当于设置了数据白名单。当加载正常数据时放行，加载异常数据时直接拦截（效率偏低），也可以使用布隆过滤器（有关布隆过滤器的命中问题对当前状况可以忽略）
 
-3. 实施监控：实时监控redis命中率（业务正常范围时，通常会有一个波动值）与null数据的占比
+3. 实施监控：实时监控 redis 命中率（业务正常范围时，通常会有一个波动值）与null数据的占比
 
    * 非活动时段波动：通常检测3-5倍，超过5倍纳入重点排查对象
    * 活动时段波动：通常检测10-50倍，超过50倍纳入重点排查对象
diff --git a/Java.md b/Java.md
@@ -14995,7 +14995,7 @@ Passenger 类的方法表包括两个方法，分别对应 0 号和 1 号。方
 
 ##### 内联缓存
 
-内联缓存：是一种加快动态绑定的优化技术，它能够缓存虚方法调用中调用者的动态类型以及该类型所对应的目标方法。在之后的执行过程中，如果碰到已缓存的类型，内联缓存便会直接调用该类型所对应的目标方法；如果没有碰到已缓存的类型，内联缓存则会退化至使用基于方法表的动态绑定
+内联缓存：是一种加快动态绑定的优化技术，它能够缓存虚方法调用中**调用者的动态类型以及该类型所对应的目标方法**。在之后的执行过程中，如果碰到已缓存的类型，内联缓存便会直接调用该类型所对应的目标方法；如果没有碰到已缓存的类型，内联缓存则会退化至使用基于方法表的动态绑定
 
 多态的三个术语：
 
diff --git a/Tool.md b/Tool.md
@@ -2205,7 +2205,9 @@ pstree -A	#查看所有进程树
 
 父进程 ID 为 0 的进程通常是内核进程，它们作为系统自举过程的一部分而启动，但 init 进程是个例外，它的父进程是0，但是它是用户进程
 
-自举程序：存储在内存中 ROM，用来加载操作系统。CPU 的程序计数器指向 ROM 中自举程序第一条指令所对应的位置，当计算机通电，CPU 开始读取并执行自举程序，将操作系统（不是全部，只是启动计算机的那部分程序）装入RAM中，这个过程是自举过程
+自举程序：存储在内存中 ROM（BIOS 芯片），用来加载操作系统。CPU 的程序计数器指向 ROM 中自举程序第一条指令所对应的位置，当计算机通电，CPU 开始读取并执行自举程序，将操作系统（不是全部，只是启动计算机的那部分程序）装入RAM中，这个过程是自举过程
+
+主存 = RAM + BIOS部分的 ROM
 
 装入完成后，CPU 的程序计数器就被设置为 RAM 中操作系统的第一条指令所对应的位置，接下来CPU将开始执行操作系统的指令
 
