Update Java Note

Seazean · Seazean · commit 3cb0150daddf · 2022-03-09T01:02:53.000+08:00
diff --git a/Frame.md b/Frame.md
@@ -9552,7 +9552,7 @@ PullAPIWrapper 类封装了拉取消息的 API
       * `PullResult pullResult`：从 response 内提取出来拉消息结果对象，将响应头 PullMessageResponseHeader 对象中信息**填充到 PullResult 中**，列出两个重要的字段：
         * `private Long suggestWhichBrokerId`：服务端建议客户端下次 Pull 时选择的 BrokerID
         * `private Long nextBeginOffset`：客户端下次 Pull 时使用的 offset 信息
-      
+  
 * `pullCallback.onSuccess(pullResult)`：将 PullResult 交给拉消息结果处理回调对象，调用 onSuccess 方法
 
 
@@ -10227,18 +10227,18 @@ ConsumeRequest 是 ConsumeMessageOrderlyService 的内部类，是一个 Runnabl
 
 生产流程：
 
-* 首先获取当前消息主题的发布信息，获取不到去 Namesrv 获取（默认有 TBW102），并将获取的到的路由数据转化为发布数据，**创建 MQ 队列**，同样更新订阅数据，创建 MQ 队列，放入负载均衡服务 topicSubscribeInfoTable 中
-* 发送消息后，会创建主题对应的 MQ 放入 SendResult
+* 首先获取当前消息主题的发布信息，获取不到去 Namesrv 获取（默认有 TBW102），并将获取的到的路由数据转化为发布数据，**创建 MQ 队列**，客户端实例同样更新订阅数据，创建 MQ 队列，放入负载均衡服务 topicSubscribeInfoTable 中
+* 然后从发布数据中选择一个 MQ 队列发送消息
 * Broker 端通过 SendMessageProcessor 对发送的消息进行持久化处理，存储到 CommitLog。将重试次数过多的消息加入死信队列，将延迟级别消息的主题和队列修改为调度主题和调度队列 ID
-* ScheduleMessageService 服务会为每个延迟级别创建一个延迟任务，让延迟消息得到有效的处理，将到达交付时间的消息修改为原始主题的原始 ID 存入 CommitLog，消费者就可以进行消费了
+* Broker 启动 ScheduleMessageService 服务会为每个延迟级别创建一个延迟任务，让延迟消息得到有效的处理，将到达交付时间的消息修改为原始主题的原始 ID 存入 CommitLog，消费者就可以进行消费了
 
 消费流程：
 
 * 首先通过负载均衡服务，将分配到当前消费者实例的 MQ 创建 PullRequest，并放入 PullMessageService 的本地阻塞队列内
-* PullMessageService 循环从阻塞队列获取请求对象，发起拉消息请求，并创建 PullCallback 回调对象，将拉取的消息**提交到消费任务线程池**，并设置下一次拉取的位点，重新放入阻塞队列，形成闭环
-* 消费任务对消费失败的消息进行回退，回退失败的消息会再次提交消费任务
-* Broker 端对拉取消息的请求进行处理（processRequestCommand），查询成功将消息放入响应体，通过 Netty 写回客户端，当 `pullRequest.offset  ==  queue.maxOffset` 说明该队列已经没有需要获取的消息，此时进行长轮询等待有新的消息
-* PullRequestHoldService 负责长轮询，每 5 秒检查一次，将满足条件的 PullRequest 再次提交到线程池内执行
+* PullMessageService 循环从阻塞队列获取请求对象，发起拉消息请求，并创建 PullCallback 回调对象，将正常拉取的消息**提交到消费任务线程池**，并设置下一次拉取的位点，重新放入阻塞队列，形成闭环
+* 消费任务服务对消费失败的消息进行回退，回退失败的消息会再次提交消费任务重新消费
+* Broker 端对拉取消息的请求进行处理（processRequestCommand），查询成功将消息放入响应体，通过 Netty 写回客户端，当 `pullRequest.offset  ==  queue.maxOffset` 说明该队列已经没有需要获取的消息，将请求放入长轮询集合等待有新消息
+* PullRequestHoldService 负责长轮询，每 5 秒遍历一次长轮询集合，将满足条件的 PullRequest 再次提交到线程池内处理
 
 
 
diff --git a/Java.md b/Java.md
@@ -11767,7 +11767,7 @@ CMS 收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿
 - 初始标记：使用 STW 出现短暂停顿，仅标记一下 GC Roots 能直接关联到的对象，速度很快
 - 并发标记：进行 GC Roots 开始遍历整个对象图，在整个回收过程中耗时最长，不需要 STW，可以与用户线程并发运行
 - 重新标记：修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，比初始标记时间长但远比并发标记时间短，需要 STW（不停顿就会一直变化，采用写屏障 + 增量更新来避免漏标情况）
-- 并发清除：清除标记为可以回收对象，不需要移动存活对象，所以这个阶段可以与用户线程同时并发的
+- 并发清除：清除标记为可以回收对象，**不需要移动存活对象**，所以这个阶段可以与用户线程同时并发的
 
 Mark Sweep 会造成内存碎片，不把算法换成 Mark Compact 的原因：
 
@@ -11922,9 +11922,9 @@ G1 中提供了三种垃圾回收模式：YoungGC、Mixed GC 和 Full GC，在
 
   * 初始标记：标记从根节点直接可达的对象，这个阶段是 STW 的，并且会触发一次年轻代 GC
   * 根区域扫描 (Root Region Scanning)：扫描 Survivor 区中指向老年代的，被初始标记标记了的引用及引用的对象，这一个过程是并发进行的，但是必须在 Young GC 之前完成
-  * 并发标记 (Concurrent Marking)：在整个堆中进行并发标记（应用程序并发执行），可能被 YoungGC 中断。会计算每个区域的对象活性，即区域中存活对象的比例，若区域中的所有对象都是垃圾，则这个区域会被立即回收（实时回收），给浮动垃圾准备出更多的空间，把需要收集的 Region 放入 CSet 当中
+  * 并发标记 (Concurrent Marking)：在整个堆中进行并发标记（应用程序并发执行），可能被 YoungGC 中断。会计算每个区域的对象活性，即区域中存活对象的比例，若区域中的所有对象都是垃圾，则这个区域会被立即回收（**实时回收**），给浮动垃圾准备出更多的空间，把需要收集的 Region 放入 CSet 当中
   * 最终标记：为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程的 Remembered Set Logs 里面，最终标记阶段需要把 Remembered Set Logs 的数据合并到 Remembered Set 中，这阶段需要停顿线程，但是可并行执行（**防止漏标**）
-  * 筛选回收：并发清理阶段，首先对 CSet 中各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划。此阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分 Region，时间是用户可控制的，而且停顿用户线程将大幅度提高收集效率
+  * 筛选回收：并发清理阶段，首先对 CSet 中各个 Region 中的回收价值和成本进行排序，根据用户所期望的 GC 停顿时间来制定回收计划，也需要 STW
 
   ![](https://gitee.com/seazean/images/raw/master/Java/JVM-G1收集器.jpg)
 
@@ -12004,7 +12004,7 @@ ZGC 收集器是一个可伸缩的、低延迟的垃圾收集器，基于 Region
   * 可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据
 * 内存多重映射：多个虚拟地址指向同一个物理地址
 
-可并发的标记压缩算法：染色指针标识对象是否被标记或移动，读屏障保证在每次应用程序或 GC 程序访问对象时先根据染色指针的标识判断是否被移动，如果被移动就根据转发表访问新的移动对象，并更新引用，不会像 G1 一样必须等待垃圾回收完成才能访问
+可并发的标记压缩算法：染色指针标识对象是否被标记或移动，读屏障保证在每次应用程序或 GC 程序访问对象时先根据染色指针的标识判断是否被移动，如果被移动就根据转发表访问新的移动对象，**并更新引用**，不会像 G1 一样必须等待垃圾回收完成才能访问
 
 ZGC 目标：
 
@@ -13309,7 +13309,7 @@ Java 语言：跨平台的语言（write once ，run anywhere）
 
 编译过程中的编译器：
 
-* 前端编译器： Sun 的全量式编译器 javac、 Eclipse 的增量式编译器 ECJ，把源代码编译为字节码文件 .class
+* 前端编译器： Sun 的全量式编译器 javac、 Eclipse 的增量式编译器 ECJ，**把源代码编译为字节码文件 .class**
 
   * IntelliJ IDEA 使用 javac 编译器
   * Eclipse 中，当开发人员编写完代码后保存时，ECJ 编译器就会把未编译部分的源码逐行进行编译，而非每次都全量编译，因此 ECJ 的编译效率会比 javac 更加迅速和高效
diff --git a/Web.md b/Web.md
@@ -2272,6 +2272,14 @@ HTTPS 工作流程：服务器端的公钥和私钥，用来进行非对称加
     * 请求报文的 HTTP 方法本身是可缓存的，包括 GET 和 HEAD，但是 PUT 和 DELETE 不可缓存，POST 在多数情况下不可缓存
     * 响应报文的状态码是可缓存的，包括：200、203、204、206、300、301、404、405、410、414 and 501
     * 响应报文的 Cache-Control 首部字段没有指定不进行缓存
+    
+  * PUT 和 POST 的区别
+
+    PUT 请求：如果两个请求相同，后一个请求会把第一个请求覆盖掉（幂等），所以 PUT 用来修改资源
+    
+    POST 请求：后一个请求不会把第一个请求覆盖掉（非幂等），所以 POST 用来创建资源
+    
+    PATCH方法 是新引入的，是对 PUT 方法的补充，用来对已知资源进行**局部更新**
 
   
 
