From 670574ecccf49ac841b1347dd874bd3967d01a24 Mon Sep 17 00:00:00 2001 From: nicksxs Date: Tue, 5 Apr 2022 20:43:55 +0800 Subject: [PATCH] Site updated: 2022-04-05 20:43:54 --- .../index.html | 2 +- .../index.html | 2 +- .../index.html | 2 +- .../聊聊-Linux-下的-top-命令/index.html | 2 +- categories/Java/GC/index.html | 2 +- categories/Java/index.html | 2 +- categories/Redis/index.html | 2 +- .../leetcode/java/linked-list/index.html | 2 +- categories/linked-list/index.html | 2 +- categories/php/index.html | 2 +- leancloud.memo | 1 + leancloud_counter_security_urls.json | 2 +- page/12/index.html | 2 +- page/17/index.html | 2 +- page/18/index.html | 2 +- page/19/index.html | 2 +- search.xml | 2674 ++++++++--------- sitemap.xml | 1216 ++++---- tags/JVM/index.html | 2 +- tags/mysql/index.html | 2 +- tags/php/index.html | 2 +- 21 files changed, 1964 insertions(+), 1963 deletions(-) diff --git a/2020/08/06/Linux-下-grep-命令的一点小技巧/index.html b/2020/08/06/Linux-下-grep-命令的一点小技巧/index.html index 55c280ebf7..5323fcf9fb 100644 --- a/2020/08/06/Linux-下-grep-命令的一点小技巧/index.html +++ b/2020/08/06/Linux-下-grep-命令的一点小技巧/index.html @@ -1,4 +1,4 @@ -Linux 下 grep 命令的一点小技巧 | Nicksxs's Blog

Nicksxs's Blog

What hurts more, the pain of hard work or the pain of regret?

0%

Linux 下 grep 命令的一点小技巧

发表于 分类于 ， ， ， ， ， 阅读次数： 阅读次数： Disqus：

用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，

譬如


+Linux 下 grep 命令的一点小技巧 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
Linux 下 grep 命令的一点小技巧
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，
譬如

 grep 'xxx' xxxx.log
 
然后有挺多情况比如想要找日志里带一些符号什么的，就需要用到一些特殊的
比如这样\"userId\":\"123456\"，因为比如用户 ID 有时候会跟其他的 id 一样，只用具体的值 123456 来查的话干扰信息太多了，如果直接这样

 grep '\"userId\":\"123456\"' xxxx.log
diff --git a/2020/09/06/mybatis-的-和-是有啥区别/index.html b/2020/09/06/mybatis-的-和-是有啥区别/index.html
index a084a7e22f..72aa27a971 100644
--- a/2020/09/06/mybatis-的-和-是有啥区别/index.html
+++ b/2020/09/06/mybatis-的-和-是有啥区别/index.html
@@ -1,4 +1,4 @@
-mybatis 的 $ 和 # 是有啥区别 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
mybatis 的 $ 和 # 是有啥区别
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条select * from t1 where id = #{id}这样的 sql，在初始化扫描 mapper 的xml文件的时候会根据是否是 dynamic 来判断生成 DynamicSqlSource 还是 RawSqlSource，这里它是一条 RawSqlSource，
在这里做了替换，将#{}替换成了?

前面说的是否 dynamic 就是在这里进行判断
// org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode
+mybatis 的 $ 和 # 是有啥区别 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
mybatis 的 $ 和 # 是有啥区别
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条select * from t1 where id = #{id}这样的 sql，在初始化扫描 mapper 的xml文件的时候会根据是否是 dynamic 来判断生成 DynamicSqlSource 还是 RawSqlSource，这里它是一条 RawSqlSource，
在这里做了替换，将#{}替换成了?

前面说的是否 dynamic 就是在这里进行判断
// org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode
 public SqlSource parseScriptNode() {
     MixedSqlNode rootSqlNode = parseDynamicTags(context);
     SqlSource sqlSource;
diff --git a/2020/10/03/mybatis-的缓存是怎么回事/index.html b/2020/10/03/mybatis-的缓存是怎么回事/index.html
index 5ea78d0b26..61760fcc49 100644
--- a/2020/10/03/mybatis-的缓存是怎么回事/index.html
+++ b/2020/10/03/mybatis-的缓存是怎么回事/index.html
@@ -1,4 +1,4 @@
-mybatis 的缓存是怎么回事 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
mybatis 的缓存是怎么回事
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
Java 真的是任何一个中间件，比较常用的那种，都有很多内容值得深挖，比如这个缓存，慢慢有过一些感悟，比如如何提升性能，缓存无疑是一大重要手段，最底层开始 CPU 就有缓存，而且又小又贵，再往上一点内存一般作为硬盘存储在运行时的存储，一般在代码里也会用内存作为一些本地缓存，譬如数据库，像 mysql 这种也是有innodb_buffer_pool来提升查询效率，本质上理解就是用更快的存储作为相对慢存储的缓存，减少查询直接访问较慢的存储，并且这个都是相对的，比起 cpu 的缓存，那内存也是渣，但是与普通机械硬盘相比，那也是两个次元的水平。
闲扯这么多来说说 mybatis 的缓存，mybatis 一般作为一个轻量级的 orm 使用，相对应的就是比较重量级的 hibernate，不过不在这次讨论范围，上一次是主要讲了 mybatis 在解析 sql 过程中，对于两种占位符的不同替换实现策略，这次主要聊下 mybatis 的缓存，前面其实得了解下前置的东西，比如 sqlsession，先当做我们知道 sqlsession 是个什么玩意，可能或多或少的知道 mybatis 是有两级缓存，
一级缓存
第一级的缓存是在 BaseExecutor 中的 PerpetualCache，它是个最基本的缓存实现类，使用了 HashMap 实现缓存功能，代码其实没几十行
public class PerpetualCache implements Cache {
+mybatis 的缓存是怎么回事 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
mybatis 的缓存是怎么回事
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
Java 真的是任何一个中间件，比较常用的那种，都有很多内容值得深挖，比如这个缓存，慢慢有过一些感悟，比如如何提升性能，缓存无疑是一大重要手段，最底层开始 CPU 就有缓存，而且又小又贵，再往上一点内存一般作为硬盘存储在运行时的存储，一般在代码里也会用内存作为一些本地缓存，譬如数据库，像 mysql 这种也是有innodb_buffer_pool来提升查询效率，本质上理解就是用更快的存储作为相对慢存储的缓存，减少查询直接访问较慢的存储，并且这个都是相对的，比起 cpu 的缓存，那内存也是渣，但是与普通机械硬盘相比，那也是两个次元的水平。
闲扯这么多来说说 mybatis 的缓存，mybatis 一般作为一个轻量级的 orm 使用，相对应的就是比较重量级的 hibernate，不过不在这次讨论范围，上一次是主要讲了 mybatis 在解析 sql 过程中，对于两种占位符的不同替换实现策略，这次主要聊下 mybatis 的缓存，前面其实得了解下前置的东西，比如 sqlsession，先当做我们知道 sqlsession 是个什么玩意，可能或多或少的知道 mybatis 是有两级缓存，
一级缓存
第一级的缓存是在 BaseExecutor 中的 PerpetualCache，它是个最基本的缓存实现类，使用了 HashMap 实现缓存功能，代码其实没几十行
public class PerpetualCache implements Cache {
 
   private final String id;
 
diff --git a/2021/03/28/聊聊-Linux-下的-top-命令/index.html b/2021/03/28/聊聊-Linux-下的-top-命令/index.html
index 9fa41b3a50..5337799c6e 100644
--- a/2021/03/28/聊聊-Linux-下的-top-命令/index.html
+++ b/2021/03/28/聊聊-Linux-下的-top-命令/index.html
@@ -1,4 +1,4 @@
-聊聊 Linux 下的 top 命令 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
聊聊 Linux 下的 top 命令
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H  :Threads-mode operation
+聊聊 Linux 下的 top 命令 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
聊聊 Linux 下的 top 命令
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H  :Threads-mode operation
             Instructs top to display individual threads.  Without this command-line option a summation of all threads in each process  is  shown.   Later
             this can be changed with the `H' interactive command.
这样就能用在 Java 中去 jstack 中找到对应的线程
其实还有比较重要的两个操作，
一个是在 top 启动状态下，按c键，这样能把比如说是一个 Java 进程，具体的进程命令显示出来
像这样
执行前是这样

执行后是这样

第二个就是排序了
SORTING of task window
 
diff --git a/categories/Java/GC/index.html b/categories/Java/GC/index.html
index 8c389491c0..93abb7d74b 100644
--- a/categories/Java/GC/index.html
+++ b/categories/Java/GC/index.html
@@ -1 +1 @@
-分类: gc | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
gc 分类
2021
© 2022  Nicksxs
   
urce/js/third-party/quicklink.min.js">
\ No newline at end of file
+分类: gc | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
gc 分类
2021
© 2022  Nicksxs
   

\ No newline at end of file
diff --git a/categories/Java/index.html b/categories/Java/index.html
index 708cd43541..c050a7b359 100644
--- a/categories/Java/index.html
+++ b/categories/Java/index.html
@@ -1 +1 @@
-分类: java | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
java 分类
2019
© 2022  Nicksxs
   
lass="post-title">
2021
© 2022  Nicksxs
   

\ No newline at end of file
+分类: java | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
java 分类
2019
© 2022  Nicksxs
   

\ No newline at end of file
diff --git a/categories/Redis/index.html b/categories/Redis/index.html
index 2cea5124ef..0edf079b64 100644
--- a/categories/Redis/index.html
+++ b/categories/Redis/index.html
@@ -1 +1 @@
-分类: redis | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
redis 分类
2021
© 2022  Nicksxs
   
>
© 2022  Nicksxs
   

\ No newline at end of file
+分类: redis | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
redis 分类
2021
© 2022  Nicksxs
   

\ No newline at end of file
diff --git a/categories/leetcode/java/linked-list/index.html b/categories/leetcode/java/linked-list/index.html
index 6840667a85..9cbd9c9326 100644
--- a/categories/leetcode/java/linked-list/index.html
+++ b/categories/leetcode/java/linked-list/index.html
@@ -1 +1 @@
-分类: linked list | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
linked list 分类
2020
© 2022  Nicksxs
   
C3YSHnEz02Z9C1UeW/E9OgnvlzSY=" crossorigin="anonymous">
\ No newline at end of file
+分类: linked list | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
linked list 分类
2020
© 2022  Nicksxs
   

\ No newline at end of file
diff --git a/categories/linked-list/index.html b/categories/linked-list/index.html
index 6ea0501a74..120d87536b 100644
--- a/categories/linked-list/index.html
+++ b/categories/linked-list/index.html
@@ -1 +1 @@
-分类: linked list | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
linked list 分类
2020
© 2022  Nicksxs
   
kQf9z5ntdQrzsBC3YSHnEz02Z9C1UeW/E9OgnvlzSY=" crossorigin="anonymous">
\ No newline at end of file
+分类: linked list | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
linked list 分类
2020
© 2022  Nicksxs
   

\ No newline at end of file
diff --git a/categories/php/index.html b/categories/php/index.html
index 4ff90b3b3c..dae79b7782 100644
--- a/categories/php/index.html
+++ b/categories/php/index.html
@@ -1 +1 @@
-分类: PHP | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
PHP 分类
2020
© 2022  Nicksxs
   
js">
\ No newline at end of file
+分类: PHP | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
PHP 分类
2020
© 2022  Nicksxs
   

\ No newline at end of file
diff --git a/leancloud.memo b/leancloud.memo
index 3f0eba9c3a..0976e898bf 100644
--- a/leancloud.memo
+++ b/leancloud.memo
@@ -154,4 +154,5 @@
 {"title":"Leetcode 83 删除排序链表中的重复元素 ( Remove Duplicates from Sorted List *Easy* ) 题解分析","url":"/2022/03/13/Leetcode-83-删除排序链表中的重复元素-Remove-Duplicates-from-Sorted-List-Easy-题解分析/"},
 {"title":"给小电驴上牌","url":"/2022/03/20/给小电驴上牌/"},
 {"title":"Leetcode 4 寻找两个正序数组的中位数 ( Median of Two Sorted Arrays *Hard* ) 题解分析","url":"/2022/03/27/Leetcode-4-寻找两个正序数组的中位数-Median-of-Two-Sorted-Arrays-Hard-题解分析/"},
+{"title":"Dubbo 使用的几个记忆点","url":"/2022/04/02/Dubbo-使用的几个记忆点/"},
 ]
\ No newline at end of file
diff --git a/leancloud_counter_security_urls.json b/leancloud_counter_security_urls.json
index 09924e4ca5..2e8bd75864 100644
--- a/leancloud_counter_security_urls.json
+++ b/leancloud_counter_security_urls.json
@@ -1 +1 @@
-[{"title":"村上春树《1Q84》读后感","url":"/2019/12/18/1Q84读后感/"},{"title":"2019年终总结","url":"/2020/02/01/2019年终总结/"},{"title":"2020 年终总结","url":"/2021/03/31/2020-年终总结/"},{"title":"2020年中总结","url":"/2020/07/11/2020年中总结/"},{"title":"2021 年中总结","url":"/2021/07/18/2021-年中总结/"},{"title":"2021 年终总结","url":"/2022/01/22/2021-年终总结/"},{"title":"34_Search_for_a_Range","url":"/2016/08/14/34-Search-for-a-Range/"},{"title":"AQS篇二 之 Condition 浅析笔记","url":"/2021/02/21/AQS-之-Condition-浅析笔记/"},{"title":"AQS篇一","url":"/2021/02/14/AQS篇一/"},{"title":"AbstractQueuedSynchronizer","url":"/2019/09/23/AbstractQueuedSynchronizer/"},{"title":"add-two-number","url":"/2015/04/14/Add-Two-Number/"},{"title":"Apollo 的 value 注解是怎么自动更新的","url":"/2020/11/01/Apollo-的-value-注解是怎么自动更新的/"},{"title":"Clone Graph Part I","url":"/2014/12/30/Clone-Graph-Part-I/"},{"title":"Comparator使用小记","url":"/2020/04/05/Comparator使用小记/"},{"title":"Disruptor 系列一","url":"/2022/02/13/Disruptor-系列一/"},{"title":"Disruptor 系列二","url":"/2022/02/27/Disruptor-系列二/"},{"title":"Dubbo 使用的几个记忆点","url":"/2022/04/02/Dubbo-使用的几个记忆点/"},{"title":"Filter, Interceptor, Aop, 啥, 啥, 啥? 这些都是啥?","url":"/2020/08/22/Filter-Intercepter-Aop-啥-啥-啥-这些都是啥/"},{"title":"G1收集器概述","url":"/2020/02/09/G1收集器概述/"},{"title":"JVM源码分析之G1垃圾收集器分析一","url":"/2019/12/07/JVM-G1-Part-1/"},{"title":"Leetcode 021 合并两个有序链表 ( Merge Two Sorted Lists ) 题解分析","url":"/2021/10/07/Leetcode-021-合并两个有序链表-Merge-Two-Sorted-Lists-题解分析/"},{"title":"Leetcode 028 实现 strStr() ( Implement strStr() ) 题解分析","url":"/2021/10/31/Leetcode-028-实现-strStr-Implement-strStr-题解分析/"},{"title":"Leetcode 053 最大子序和 ( Maximum Subarray ) 题解分析","url":"/2021/11/28/Leetcode-053-最大子序和-Maximum-Subarray-题解分析/"},{"title":"Leetcode 104 二叉树的最大深度(Maximum Depth of Binary Tree) 题解分析","url":"/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/"},{"title":"Leetcode 105 从前序与中序遍历序列构造二叉树(Construct Binary Tree from Preorder and Inorder Traversal) 题解分析","url":"/2020/12/13/Leetcode-105-从前序与中序遍历序列构造二叉树-Construct-Binary-Tree-from-Preorder-and-Inorder-Traversal-题解分析/"},{"title":"Leetcode 121 买卖股票的最佳时机(Best Time to Buy and Sell Stock) 题解分析","url":"/2021/03/14/Leetcode-121-买卖股票的最佳时机-Best-Time-to-Buy-and-Sell-Stock-题解分析/"},{"title":"Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析","url":"/2021/01/24/Leetcode-124-二叉树中的最大路径和-Binary-Tree-Maximum-Path-Sum-题解分析/"},{"title":"Leetcode 155 最小栈(Min Stack) 题解分析","url":"/2020/12/06/Leetcode-155-最小栈-Min-Stack-题解分析/"},{"title":"Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析","url":"/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/"},{"title":"Leetcode 2 Add Two Numbers 题解分析","url":"/2020/10/11/Leetcode-2-Add-Two-Numbers-题解分析/"},{"title":"Leetcode 234 回文链表(Palindrome Linked List) 题解分析","url":"/2020/11/15/Leetcode-234-回文联表-Palindrome-Linked-List-题解分析/"},{"title":"Leetcode 236 二叉树的最近公共祖先(Lowest Common Ancestor of a Binary Tree) 题解分析","url":"/2021/05/23/Leetcode-236-二叉树的最近公共祖先-Lowest-Common-Ancestor-of-a-Binary-Tree-题解分析/"},{"title":"Leetcode 3 Longest Substring Without Repeating Characters 题解分析","url":"/2020/09/20/Leetcode-3-Longest-Substring-Without-Repeating-Characters-题解分析/"},{"title":"Leetcode 349 两个数组的交集 ( Intersection of Two Arrays *Easy* ) 题解分析","url":"/2022/03/07/Leetcode-349-两个数组的交集-Intersection-of-Two-Arrays-Easy-题解分析/"},{"title":"Leetcode 4 寻找两个正序数组的中位数 ( Median of Two Sorted Arrays *Hard* ) 题解分析","url":"/2022/03/27/Leetcode-4-寻找两个正序数组的中位数-Median-of-Two-Sorted-Arrays-Hard-题解分析/"},{"title":"Leetcode 42 接雨水 (Trapping Rain Water) 题解分析","url":"/2021/07/04/Leetcode-42-接雨水-Trapping-Rain-Water-题解分析/"},{"title":"Leetcode 48 旋转图像(Rotate Image) 题解分析","url":"/2021/05/01/Leetcode-48-旋转图像-Rotate-Image-题解分析/"},{"title":"Leetcode 83 删除排序链表中的重复元素 ( Remove Duplicates from Sorted List *Easy* ) 题解分析","url":"/2022/03/13/Leetcode-83-删除排序链表中的重复元素-Remove-Duplicates-from-Sorted-List-Easy-题解分析/"},{"title":"leetcode no.3","url":"/2015/04/15/Leetcode-No-3/"},{"title":"Linux 下 grep 命令的一点小技巧","url":"/2020/08/06/Linux-下-grep-命令的一点小技巧/"},{"title":"MFC 模态对话框","url":"/2014/12/24/MFC 模态对话框/"},{"title":"Maven实用小技巧","url":"/2020/02/16/Maven实用小技巧/"},{"title":"Number of 1 Bits","url":"/2015/03/11/Number-Of-1-Bits/"},{"title":"Path Sum","url":"/2015/01/04/Path-Sum/"},{"title":"Redis_分布式锁","url":"/2019/12/10/Redis-Part-1/"},{"title":"Reverse Bits","url":"/2015/03/11/Reverse-Bits/"},{"title":"Reverse Integer","url":"/2015/03/13/Reverse-Integer/"},{"title":"two sum","url":"/2015/01/14/Two-Sum/"},{"title":"ambari-summary","url":"/2017/05/09/ambari-summary/"},{"title":"binary-watch","url":"/2016/09/29/binary-watch/"},{"title":"docker-mysql-cluster","url":"/2016/08/14/docker-mysql-cluster/"},{"title":"docker比一般多一点的初学者介绍","url":"/2020/03/08/docker比一般多一点的初学者介绍/"},{"title":"docker比一般多一点的初学者介绍三","url":"/2020/03/21/docker比一般多一点的初学者介绍三/"},{"title":"docker比一般多一点的初学者介绍二","url":"/2020/03/15/docker比一般多一点的初学者介绍二/"},{"title":"docker使用中发现的echo命令的一个小技巧及其他","url":"/2020/03/29/echo命令的一个小技巧/"},{"title":"gogs使用webhook部署react单页应用","url":"/2020/02/22/gogs使用webhook部署react单页应用/"},{"title":"invert-binary-tree","url":"/2015/06/22/invert-binary-tree/"},{"title":"minimum-size-subarray-sum-209","url":"/2016/10/11/minimum-size-subarray-sum-209/"},{"title":"C++ 指针使用中的一个小问题","url":"/2014/12/23/my-new-post/"},{"title":"mybatis 的 $ 和 # 是有啥区别","url":"/2020/09/06/mybatis-的-和-是有啥区别/"},{"title":"mybatis 的缓存是怎么回事","url":"/2020/10/03/mybatis-的缓存是怎么回事/"},{"title":"openresty","url":"/2019/06/18/openresty/"},{"title":"pcre-intro-and-a-simple-package","url":"/2015/01/16/pcre-intro-and-a-simple-package/"},{"title":"php-abstract-class-and-interface","url":"/2016/11/10/php-abstract-class-and-interface/"},{"title":"rabbitmq-tips","url":"/2017/04/25/rabbitmq-tips/"},{"title":"redis 的 rdb 和 COW 介绍","url":"/2021/08/15/redis-的-rdb-和-COW-介绍/"},{"title":"redis数据结构介绍-第一部分 SDS，链表，字典","url":"/2019/12/26/redis数据结构介绍/"},{"title":"redis数据结构介绍三-第三部分 整数集合","url":"/2020/01/10/redis数据结构介绍三/"},{"title":"redis数据结构介绍二-第二部分 跳表","url":"/2020/01/04/redis数据结构介绍二/"},{"title":"redis数据结构介绍五-第五部分 对象","url":"/2020/01/20/redis数据结构介绍五/"},{"title":"redis数据结构介绍六 快表","url":"/2020/01/22/redis数据结构介绍六/"},{"title":"redis淘汰策略复习","url":"/2021/08/01/redis淘汰策略复习/"},{"title":"redis数据结构介绍四-第四部分 压缩表","url":"/2020/01/19/redis数据结构介绍四/"},{"title":"redis系列介绍七-过期策略","url":"/2020/04/12/redis系列介绍七/"},{"title":"redis系列介绍八-淘汰策略","url":"/2020/04/18/redis系列介绍八/"},{"title":"redis过期策略复习","url":"/2021/07/25/redis过期策略复习/"},{"title":"rust学习笔记-所有权三之切片","url":"/2021/05/16/rust学习笔记-所有权三之切片/"},{"title":"rust学习笔记-所有权二","url":"/2021/04/18/rust学习笔记-所有权二/"},{"title":"rust学习笔记-所有权一","url":"/2021/04/18/rust学习笔记/"},{"title":"spark-little-tips","url":"/2017/03/28/spark-little-tips/"},{"title":"spring event 介绍","url":"/2022/01/30/spring-event-介绍/"},{"title":"summary-ranges-228","url":"/2016/10/12/summary-ranges-228/"},{"title":"swoole-websocket-test","url":"/2016/07/13/swoole-websocket-test/"},{"title":"wordpress 忘记密码的一种解决方法","url":"/2021/12/05/wordpress-忘记密码的一种解决方法/"},{"title":"《垃圾回收算法手册读书》笔记之整理算法","url":"/2021/03/07/《垃圾回收算法手册读书》笔记之整理算法/"},{"title":"上次的其他 外行聊国足","url":"/2022/03/06/上次的其他-外行聊国足/"},{"title":"介绍一下 RocketMQ","url":"/2020/06/21/介绍一下-RocketMQ/"},{"title":"介绍下最近比较实用的端口转发","url":"/2021/11/14/介绍下最近比较实用的端口转发/"},{"title":"从丁仲礼被美国制裁聊点啥","url":"/2020/12/20/从丁仲礼被美国制裁聊点啥/"},{"title":"从清华美院学姐聊聊我们身边的恶人","url":"/2020/11/29/从清华美院学姐聊聊我们身边的恶人/"},{"title":"关于公共交通再吐个槽","url":"/2021/03/21/关于公共交通再吐个槽/"},{"title":"关于读书打卡与分享","url":"/2021/02/07/关于读书打卡与分享/"},{"title":"分享记录一下一个 git 操作方法","url":"/2022/02/06/分享记录一下一个-git-操作方法/"},{"title":"分享记录一下一个 scp 操作方法","url":"/2022/02/06/分享记录一下一个-scp-操作方法/"},{"title":"周末我在老丈人家打了天小工","url":"/2020/08/16/周末我在老丈人家打了天小工/"},{"title":"在老丈人家的小工记三","url":"/2020/09/13/在老丈人家的小工记三/"},{"title":"在老丈人家的小工记五","url":"/2020/10/18/在老丈人家的小工记五/"},{"title":"在老丈人家的小工记四","url":"/2020/09/26/在老丈人家的小工记四/"},{"title":"寄生虫观后感","url":"/2020/03/01/寄生虫观后感/"},{"title":"我是如何走上跑步这条不归路的","url":"/2020/07/26/我是如何走上跑步这条不归路的/"},{"title":"搬运两个 StackOverflow 上的 Mysql 编码相关的问题解答","url":"/2022/01/16/搬运两个-StackOverflow-上的-Mysql-编码相关的问题解答/"},{"title":"看完了扫黑风暴,聊聊感想","url":"/2021/10/24/看完了扫黑风暴-聊聊感想/"},{"title":"给小电驴上牌","url":"/2022/03/20/给小电驴上牌/"},{"title":"聊一下 RocketMQ 的 DefaultMQPushConsumer 源码","url":"/2020/06/26/聊一下-RocketMQ-的-Consumer/"},{"title":"聊一下 RocketMQ 的 NameServer 源码","url":"/2020/07/05/聊一下-RocketMQ-的-NameServer-源码/"},{"title":"聊一下 RocketMQ 的消息存储之 MMAP","url":"/2021/09/04/聊一下-RocketMQ-的消息存储/"},{"title":"聊一下 RocketMQ 的消息存储三","url":"/2021/10/03/聊一下-RocketMQ-的消息存储三/"},{"title":"聊一下 RocketMQ 的消息存储二","url":"/2021/09/12/聊一下-RocketMQ-的消息存储二/"},{"title":"聊一下 RocketMQ 的消息存储四","url":"/2021/10/17/聊一下-RocketMQ-的消息存储四/"},{"title":"聊一下 RocketMQ 的顺序消息","url":"/2021/08/29/聊一下-RocketMQ-的顺序消息/"},{"title":"聊一下 SpringBoot 中使用的 cglib 作为动态代理中的一个注意点","url":"/2021/09/19/聊一下-SpringBoot-中使用的-cglib-作为动态代理中的一个注意点/"},{"title":"聊一下 SpringBoot 中动态切换数据源的方法","url":"/2021/09/26/聊一下-SpringBoot-中动态切换数据源的方法/"},{"title":"聊在东京奥运会闭幕式这天-二","url":"/2021/08/19/聊在东京奥运会闭幕式这天-二/"},{"title":"聊在东京奥运会闭幕式这天","url":"/2021/08/08/聊在东京奥运会闭幕式这天/"},{"title":"聊聊 Dubbo 的 SPI 续之自适应拓展","url":"/2020/06/06/聊聊-Dubbo-的-SPI-续之自适应拓展/"},{"title":"聊聊 Dubbo 的 SPI","url":"/2020/05/31/聊聊-Dubbo-的-SPI/"},{"title":"聊聊 Dubbo 的容错机制","url":"/2020/11/22/聊聊-Dubbo-的容错机制/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字-二","url":"/2021/06/27/聊聊-Java-中绕不开的-Synchronized-关键字-二/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字","url":"/2021/06/20/聊聊-Java-中绕不开的-Synchronized-关键字/"},{"title":"聊聊 Java 的 equals 和 hashCode 方法","url":"/2021/01/03/聊聊-Java-的-equals-和-hashCode-方法/"},{"title":"聊聊 Java 的类加载机制一","url":"/2020/11/08/聊聊-Java-的类加载机制/"},{"title":"聊聊 Java 的类加载机制二","url":"/2021/06/13/聊聊-Java-的类加载机制二/"},{"title":"聊聊 Java 自带的那些*逆天*工具","url":"/2020/08/02/聊聊-Java-自带的那些逆天工具/"},{"title":"聊聊 Linux 下的 top 命令","url":"/2021/03/28/聊聊-Linux-下的-top-命令/"},{"title":"聊聊 RocketMQ 的 Broker 源码","url":"/2020/07/19/聊聊-RocketMQ-的-Broker-源码/"},{"title":"聊聊 Sharding-Jdbc 分库分表下的分页方案","url":"/2022/01/09/聊聊-Sharding-Jdbc-分库分表下的分页方案/"},{"title":"聊聊 Sharding-Jdbc 的简单使用","url":"/2021/12/12/聊聊-Sharding-Jdbc-的简单使用/"},{"title":"聊聊 Sharding-Jdbc 的简单原理初篇","url":"/2021/12/26/聊聊-Sharding-Jdbc-的简单原理初篇/"},{"title":"聊聊 dubbo 的线程池","url":"/2021/04/04/聊聊-dubbo-的线程池/"},{"title":"聊聊 mysql 的 MVCC 续篇","url":"/2020/05/02/聊聊-mysql-的-MVCC-续篇/"},{"title":"聊聊 mysql 的 MVCC 续续篇之锁分析","url":"/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/"},{"title":"聊聊 mysql 的 MVCC","url":"/2020/04/26/聊聊-mysql-的-MVCC/"},{"title":"聊聊 mysql 索引的一些细节","url":"/2020/12/27/聊聊-mysql-索引的一些细节/"},{"title":"聊聊 redis 缓存的应用问题","url":"/2021/01/31/聊聊-redis-缓存的应用问题/"},{"title":"聊聊Java中的单例模式","url":"/2019/12/21/聊聊Java中的单例模式/"},{"title":"聊聊 SpringBoot 自动装配","url":"/2021/07/11/聊聊SpringBoot-自动装配/"},{"title":"聊聊一次 brew update 引发的血案","url":"/2020/06/13/聊聊一次-brew-update-引发的血案/"},{"title":"聊聊传说中的 ThreadLocal","url":"/2021/05/30/聊聊传说中的-ThreadLocal/"},{"title":"聊聊厦门旅游的好与不好","url":"/2021/04/11/聊聊厦门旅游的好与不好/"},{"title":"聊聊如何识别和意识到日常生活中的各类危险","url":"/2021/06/06/聊聊如何识别和意识到日常生活中的各类危险/"},{"title":"聊聊我刚学会的应用诊断方法","url":"/2020/05/22/聊聊我刚学会的应用诊断方法/"},{"title":"聊聊我理解的分布式事务","url":"/2020/05/17/聊聊我理解的分布式事务/"},{"title":"聊聊最近平淡的生活之又聊通勤","url":"/2021/11/07/聊聊最近平淡的生活/"},{"title":"聊聊最近平淡的生活之《花束般的恋爱》观后感","url":"/2021/12/31/聊聊最近平淡的生活之《花束般的恋爱》观后感/"},{"title":"聊聊最近平淡的生活之看《神探狄仁杰》","url":"/2021/12/19/聊聊最近平淡的生活之看《神探狄仁杰》/"},{"title":"聊聊最近平淡的生活之看看老剧","url":"/2021/11/21/聊聊最近平淡的生活之看看老剧/"},{"title":"聊聊给亲戚朋友的老电脑重装系统那些事儿","url":"/2021/05/09/聊聊给亲戚朋友的老电脑重装系统那些事儿/"},{"title":"聊聊这次换车牌及其他","url":"/2022/02/20/聊聊这次换车牌及其他/"},{"title":"聊聊那些加塞狗","url":"/2021/01/17/聊聊那些加塞狗/"},{"title":"聊聊部分公交车的设计bug","url":"/2021/12/05/聊聊部分公交车的设计bug/"},{"title":"这周末我又在老丈人家打了天小工","url":"/2020/08/30/这周末我又在老丈人家打了天小工/"},{"title":"重看了下《蛮荒记》说说感受","url":"/2021/10/10/重看了下《蛮荒记》说说感受/"},{"title":"闲聊下乘公交的用户体验","url":"/2021/02/28/闲聊下乘公交的用户体验/"}]
\ No newline at end of file
+[{"title":"2019年终总结","url":"/2020/02/01/2019年终总结/"},{"title":"2020 年终总结","url":"/2021/03/31/2020-年终总结/"},{"title":"村上春树《1Q84》读后感","url":"/2019/12/18/1Q84读后感/"},{"title":"2020年中总结","url":"/2020/07/11/2020年中总结/"},{"title":"34_Search_for_a_Range","url":"/2016/08/14/34-Search-for-a-Range/"},{"title":"AQS篇二 之 Condition 浅析笔记","url":"/2021/02/21/AQS-之-Condition-浅析笔记/"},{"title":"2021 年中总结","url":"/2021/07/18/2021-年中总结/"},{"title":"AbstractQueuedSynchronizer","url":"/2019/09/23/AbstractQueuedSynchronizer/"},{"title":"add-two-number","url":"/2015/04/14/Add-Two-Number/"},{"title":"Apollo 的 value 注解是怎么自动更新的","url":"/2020/11/01/Apollo-的-value-注解是怎么自动更新的/"},{"title":"Clone Graph Part I","url":"/2014/12/30/Clone-Graph-Part-I/"},{"title":"Comparator使用小记","url":"/2020/04/05/Comparator使用小记/"},{"title":"AQS篇一","url":"/2021/02/14/AQS篇一/"},{"title":"2021 年终总结","url":"/2022/01/22/2021-年终总结/"},{"title":"Dubbo 使用的几个记忆点","url":"/2022/04/02/Dubbo-使用的几个记忆点/"},{"title":"Filter, Interceptor, Aop, 啥, 啥, 啥? 这些都是啥?","url":"/2020/08/22/Filter-Intercepter-Aop-啥-啥-啥-这些都是啥/"},{"title":"G1收集器概述","url":"/2020/02/09/G1收集器概述/"},{"title":"JVM源码分析之G1垃圾收集器分析一","url":"/2019/12/07/JVM-G1-Part-1/"},{"title":"Leetcode 021 合并两个有序链表 ( Merge Two Sorted Lists ) 题解分析","url":"/2021/10/07/Leetcode-021-合并两个有序链表-Merge-Two-Sorted-Lists-题解分析/"},{"title":"Disruptor 系列二","url":"/2022/02/27/Disruptor-系列二/"},{"title":"Leetcode 028 实现 strStr() ( Implement strStr() ) 题解分析","url":"/2021/10/31/Leetcode-028-实现-strStr-Implement-strStr-题解分析/"},{"title":"Leetcode 053 最大子序和 ( Maximum Subarray ) 题解分析","url":"/2021/11/28/Leetcode-053-最大子序和-Maximum-Subarray-题解分析/"},{"title":"Leetcode 104 二叉树的最大深度(Maximum Depth of Binary Tree) 题解分析","url":"/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/"},{"title":"Leetcode 105 从前序与中序遍历序列构造二叉树(Construct Binary Tree from Preorder and Inorder Traversal) 题解分析","url":"/2020/12/13/Leetcode-105-从前序与中序遍历序列构造二叉树-Construct-Binary-Tree-from-Preorder-and-Inorder-Traversal-题解分析/"},{"title":"Leetcode 121 买卖股票的最佳时机(Best Time to Buy and Sell Stock) 题解分析","url":"/2021/03/14/Leetcode-121-买卖股票的最佳时机-Best-Time-to-Buy-and-Sell-Stock-题解分析/"},{"title":"Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析","url":"/2021/01/24/Leetcode-124-二叉树中的最大路径和-Binary-Tree-Maximum-Path-Sum-题解分析/"},{"title":"Disruptor 系列一","url":"/2022/02/13/Disruptor-系列一/"},{"title":"Leetcode 155 最小栈(Min Stack) 题解分析","url":"/2020/12/06/Leetcode-155-最小栈-Min-Stack-题解分析/"},{"title":"Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析","url":"/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/"},{"title":"Leetcode 2 Add Two Numbers 题解分析","url":"/2020/10/11/Leetcode-2-Add-Two-Numbers-题解分析/"},{"title":"Leetcode 234 回文链表(Palindrome Linked List) 题解分析","url":"/2020/11/15/Leetcode-234-回文联表-Palindrome-Linked-List-题解分析/"},{"title":"Leetcode 236 二叉树的最近公共祖先(Lowest Common Ancestor of a Binary Tree) 题解分析","url":"/2021/05/23/Leetcode-236-二叉树的最近公共祖先-Lowest-Common-Ancestor-of-a-Binary-Tree-题解分析/"},{"title":"Leetcode 3 Longest Substring Without Repeating Characters 题解分析","url":"/2020/09/20/Leetcode-3-Longest-Substring-Without-Repeating-Characters-题解分析/"},{"title":"Leetcode 4 寻找两个正序数组的中位数 ( Median of Two Sorted Arrays *Hard* ) 题解分析","url":"/2022/03/27/Leetcode-4-寻找两个正序数组的中位数-Median-of-Two-Sorted-Arrays-Hard-题解分析/"},{"title":"Leetcode 42 接雨水 (Trapping Rain Water) 题解分析","url":"/2021/07/04/Leetcode-42-接雨水-Trapping-Rain-Water-题解分析/"},{"title":"Leetcode 349 两个数组的交集 ( Intersection of Two Arrays *Easy* ) 题解分析","url":"/2022/03/07/Leetcode-349-两个数组的交集-Intersection-of-Two-Arrays-Easy-题解分析/"},{"title":"Leetcode 48 旋转图像(Rotate Image) 题解分析","url":"/2021/05/01/Leetcode-48-旋转图像-Rotate-Image-题解分析/"},{"title":"Leetcode 83 删除排序链表中的重复元素 ( Remove Duplicates from Sorted List *Easy* ) 题解分析","url":"/2022/03/13/Leetcode-83-删除排序链表中的重复元素-Remove-Duplicates-from-Sorted-List-Easy-题解分析/"},{"title":"leetcode no.3","url":"/2015/04/15/Leetcode-No-3/"},{"title":"Linux 下 grep 命令的一点小技巧","url":"/2020/08/06/Linux-下-grep-命令的一点小技巧/"},{"title":"MFC 模态对话框","url":"/2014/12/24/MFC 模态对话框/"},{"title":"Maven实用小技巧","url":"/2020/02/16/Maven实用小技巧/"},{"title":"Number of 1 Bits","url":"/2015/03/11/Number-Of-1-Bits/"},{"title":"Path Sum","url":"/2015/01/04/Path-Sum/"},{"title":"Redis_分布式锁","url":"/2019/12/10/Redis-Part-1/"},{"title":"Reverse Bits","url":"/2015/03/11/Reverse-Bits/"},{"title":"Reverse Integer","url":"/2015/03/13/Reverse-Integer/"},{"title":"two sum","url":"/2015/01/14/Two-Sum/"},{"title":"ambari-summary","url":"/2017/05/09/ambari-summary/"},{"title":"binary-watch","url":"/2016/09/29/binary-watch/"},{"title":"docker-mysql-cluster","url":"/2016/08/14/docker-mysql-cluster/"},{"title":"docker比一般多一点的初学者介绍","url":"/2020/03/08/docker比一般多一点的初学者介绍/"},{"title":"docker比一般多一点的初学者介绍三","url":"/2020/03/21/docker比一般多一点的初学者介绍三/"},{"title":"docker比一般多一点的初学者介绍二","url":"/2020/03/15/docker比一般多一点的初学者介绍二/"},{"title":"docker使用中发现的echo命令的一个小技巧及其他","url":"/2020/03/29/echo命令的一个小技巧/"},{"title":"gogs使用webhook部署react单页应用","url":"/2020/02/22/gogs使用webhook部署react单页应用/"},{"title":"invert-binary-tree","url":"/2015/06/22/invert-binary-tree/"},{"title":"minimum-size-subarray-sum-209","url":"/2016/10/11/minimum-size-subarray-sum-209/"},{"title":"C++ 指针使用中的一个小问题","url":"/2014/12/23/my-new-post/"},{"title":"mybatis 的 $ 和 # 是有啥区别","url":"/2020/09/06/mybatis-的-和-是有啥区别/"},{"title":"mybatis 的缓存是怎么回事","url":"/2020/10/03/mybatis-的缓存是怎么回事/"},{"title":"openresty","url":"/2019/06/18/openresty/"},{"title":"pcre-intro-and-a-simple-package","url":"/2015/01/16/pcre-intro-and-a-simple-package/"},{"title":"php-abstract-class-and-interface","url":"/2016/11/10/php-abstract-class-and-interface/"},{"title":"rabbitmq-tips","url":"/2017/04/25/rabbitmq-tips/"},{"title":"redis 的 rdb 和 COW 介绍","url":"/2021/08/15/redis-的-rdb-和-COW-介绍/"},{"title":"redis数据结构介绍-第一部分 SDS，链表，字典","url":"/2019/12/26/redis数据结构介绍/"},{"title":"redis数据结构介绍三-第三部分 整数集合","url":"/2020/01/10/redis数据结构介绍三/"},{"title":"redis数据结构介绍二-第二部分 跳表","url":"/2020/01/04/redis数据结构介绍二/"},{"title":"redis数据结构介绍五-第五部分 对象","url":"/2020/01/20/redis数据结构介绍五/"},{"title":"redis数据结构介绍六 快表","url":"/2020/01/22/redis数据结构介绍六/"},{"title":"redis数据结构介绍四-第四部分 压缩表","url":"/2020/01/19/redis数据结构介绍四/"},{"title":"redis淘汰策略复习","url":"/2021/08/01/redis淘汰策略复习/"},{"title":"redis系列介绍七-过期策略","url":"/2020/04/12/redis系列介绍七/"},{"title":"redis系列介绍八-淘汰策略","url":"/2020/04/18/redis系列介绍八/"},{"title":"redis过期策略复习","url":"/2021/07/25/redis过期策略复习/"},{"title":"rust学习笔记-所有权二","url":"/2021/04/18/rust学习笔记-所有权二/"},{"title":"rust学习笔记-所有权三之切片","url":"/2021/05/16/rust学习笔记-所有权三之切片/"},{"title":"rust学习笔记-所有权一","url":"/2021/04/18/rust学习笔记/"},{"title":"spark-little-tips","url":"/2017/03/28/spark-little-tips/"},{"title":"spring event 介绍","url":"/2022/01/30/spring-event-介绍/"},{"title":"summary-ranges-228","url":"/2016/10/12/summary-ranges-228/"},{"title":"swoole-websocket-test","url":"/2016/07/13/swoole-websocket-test/"},{"title":"wordpress 忘记密码的一种解决方法","url":"/2021/12/05/wordpress-忘记密码的一种解决方法/"},{"title":"《垃圾回收算法手册读书》笔记之整理算法","url":"/2021/03/07/《垃圾回收算法手册读书》笔记之整理算法/"},{"title":"介绍一下 RocketMQ","url":"/2020/06/21/介绍一下-RocketMQ/"},{"title":"介绍下最近比较实用的端口转发","url":"/2021/11/14/介绍下最近比较实用的端口转发/"},{"title":"从丁仲礼被美国制裁聊点啥","url":"/2020/12/20/从丁仲礼被美国制裁聊点啥/"},{"title":"从清华美院学姐聊聊我们身边的恶人","url":"/2020/11/29/从清华美院学姐聊聊我们身边的恶人/"},{"title":"关于公共交通再吐个槽","url":"/2021/03/21/关于公共交通再吐个槽/"},{"title":"关于读书打卡与分享","url":"/2021/02/07/关于读书打卡与分享/"},{"title":"周末我在老丈人家打了天小工","url":"/2020/08/16/周末我在老丈人家打了天小工/"},{"title":"在老丈人家的小工记三","url":"/2020/09/13/在老丈人家的小工记三/"},{"title":"在老丈人家的小工记五","url":"/2020/10/18/在老丈人家的小工记五/"},{"title":"上次的其他 外行聊国足","url":"/2022/03/06/上次的其他-外行聊国足/"},{"title":"在老丈人家的小工记四","url":"/2020/09/26/在老丈人家的小工记四/"},{"title":"寄生虫观后感","url":"/2020/03/01/寄生虫观后感/"},{"title":"我是如何走上跑步这条不归路的","url":"/2020/07/26/我是如何走上跑步这条不归路的/"},{"title":"看完了扫黑风暴,聊聊感想","url":"/2021/10/24/看完了扫黑风暴-聊聊感想/"},{"title":"分享记录一下一个 git 操作方法","url":"/2022/02/06/分享记录一下一个-git-操作方法/"},{"title":"分享记录一下一个 scp 操作方法","url":"/2022/02/06/分享记录一下一个-scp-操作方法/"},{"title":"聊一下 RocketMQ 的 DefaultMQPushConsumer 源码","url":"/2020/06/26/聊一下-RocketMQ-的-Consumer/"},{"title":"聊一下 RocketMQ 的 NameServer 源码","url":"/2020/07/05/聊一下-RocketMQ-的-NameServer-源码/"},{"title":"聊一下 RocketMQ 的消息存储之 MMAP","url":"/2021/09/04/聊一下-RocketMQ-的消息存储/"},{"title":"聊一下 RocketMQ 的消息存储三","url":"/2021/10/03/聊一下-RocketMQ-的消息存储三/"},{"title":"聊一下 RocketMQ 的消息存储二","url":"/2021/09/12/聊一下-RocketMQ-的消息存储二/"},{"title":"聊一下 RocketMQ 的消息存储四","url":"/2021/10/17/聊一下-RocketMQ-的消息存储四/"},{"title":"聊一下 RocketMQ 的顺序消息","url":"/2021/08/29/聊一下-RocketMQ-的顺序消息/"},{"title":"聊一下 SpringBoot 中动态切换数据源的方法","url":"/2021/09/26/聊一下-SpringBoot-中动态切换数据源的方法/"},{"title":"聊一下 SpringBoot 中使用的 cglib 作为动态代理中的一个注意点","url":"/2021/09/19/聊一下-SpringBoot-中使用的-cglib-作为动态代理中的一个注意点/"},{"title":"聊在东京奥运会闭幕式这天-二","url":"/2021/08/19/聊在东京奥运会闭幕式这天-二/"},{"title":"聊在东京奥运会闭幕式这天","url":"/2021/08/08/聊在东京奥运会闭幕式这天/"},{"title":"聊聊 Dubbo 的 SPI","url":"/2020/05/31/聊聊-Dubbo-的-SPI/"},{"title":"聊聊 Dubbo 的 SPI 续之自适应拓展","url":"/2020/06/06/聊聊-Dubbo-的-SPI-续之自适应拓展/"},{"title":"聊聊 Dubbo 的容错机制","url":"/2020/11/22/聊聊-Dubbo-的容错机制/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字-二","url":"/2021/06/27/聊聊-Java-中绕不开的-Synchronized-关键字-二/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字","url":"/2021/06/20/聊聊-Java-中绕不开的-Synchronized-关键字/"},{"title":"聊聊 Java 的 equals 和 hashCode 方法","url":"/2021/01/03/聊聊-Java-的-equals-和-hashCode-方法/"},{"title":"聊聊 Java 的类加载机制一","url":"/2020/11/08/聊聊-Java-的类加载机制/"},{"title":"聊聊 Java 的类加载机制二","url":"/2021/06/13/聊聊-Java-的类加载机制二/"},{"title":"聊聊 Java 自带的那些*逆天*工具","url":"/2020/08/02/聊聊-Java-自带的那些逆天工具/"},{"title":"聊聊 Linux 下的 top 命令","url":"/2021/03/28/聊聊-Linux-下的-top-命令/"},{"title":"搬运两个 StackOverflow 上的 Mysql 编码相关的问题解答","url":"/2022/01/16/搬运两个-StackOverflow-上的-Mysql-编码相关的问题解答/"},{"title":"聊聊 RocketMQ 的 Broker 源码","url":"/2020/07/19/聊聊-RocketMQ-的-Broker-源码/"},{"title":"给小电驴上牌","url":"/2022/03/20/给小电驴上牌/"},{"title":"聊聊 Sharding-Jdbc 的简单使用","url":"/2021/12/12/聊聊-Sharding-Jdbc-的简单使用/"},{"title":"聊聊 dubbo 的线程池","url":"/2021/04/04/聊聊-dubbo-的线程池/"},{"title":"聊聊 mysql 的 MVCC 续篇","url":"/2020/05/02/聊聊-mysql-的-MVCC-续篇/"},{"title":"聊聊 mysql 的 MVCC 续续篇之锁分析","url":"/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/"},{"title":"聊聊 mysql 的 MVCC","url":"/2020/04/26/聊聊-mysql-的-MVCC/"},{"title":"聊聊 mysql 索引的一些细节","url":"/2020/12/27/聊聊-mysql-索引的一些细节/"},{"title":"聊聊 redis 缓存的应用问题","url":"/2021/01/31/聊聊-redis-缓存的应用问题/"},{"title":"聊聊Java中的单例模式","url":"/2019/12/21/聊聊Java中的单例模式/"},{"title":"聊聊 SpringBoot 自动装配","url":"/2021/07/11/聊聊SpringBoot-自动装配/"},{"title":"聊聊 Sharding-Jdbc 的简单原理初篇","url":"/2021/12/26/聊聊-Sharding-Jdbc-的简单原理初篇/"},{"title":"聊聊 Sharding-Jdbc 分库分表下的分页方案","url":"/2022/01/09/聊聊-Sharding-Jdbc-分库分表下的分页方案/"},{"title":"聊聊一次 brew update 引发的血案","url":"/2020/06/13/聊聊一次-brew-update-引发的血案/"},{"title":"聊聊传说中的 ThreadLocal","url":"/2021/05/30/聊聊传说中的-ThreadLocal/"},{"title":"聊聊厦门旅游的好与不好","url":"/2021/04/11/聊聊厦门旅游的好与不好/"},{"title":"聊聊如何识别和意识到日常生活中的各类危险","url":"/2021/06/06/聊聊如何识别和意识到日常生活中的各类危险/"},{"title":"聊聊我刚学会的应用诊断方法","url":"/2020/05/22/聊聊我刚学会的应用诊断方法/"},{"title":"聊聊我理解的分布式事务","url":"/2020/05/17/聊聊我理解的分布式事务/"},{"title":"聊聊最近平淡的生活之又聊通勤","url":"/2021/11/07/聊聊最近平淡的生活/"},{"title":"聊聊最近平淡的生活之看《神探狄仁杰》","url":"/2021/12/19/聊聊最近平淡的生活之看《神探狄仁杰》/"},{"title":"聊聊给亲戚朋友的老电脑重装系统那些事儿","url":"/2021/05/09/聊聊给亲戚朋友的老电脑重装系统那些事儿/"},{"title":"聊聊最近平淡的生活之看看老剧","url":"/2021/11/21/聊聊最近平淡的生活之看看老剧/"},{"title":"聊聊那些加塞狗","url":"/2021/01/17/聊聊那些加塞狗/"},{"title":"聊聊部分公交车的设计bug","url":"/2021/12/05/聊聊部分公交车的设计bug/"},{"title":"这周末我又在老丈人家打了天小工","url":"/2020/08/30/这周末我又在老丈人家打了天小工/"},{"title":"重看了下《蛮荒记》说说感受","url":"/2021/10/10/重看了下《蛮荒记》说说感受/"},{"title":"闲聊下乘公交的用户体验","url":"/2021/02/28/闲聊下乘公交的用户体验/"},{"title":"聊聊最近平淡的生活之《花束般的恋爱》观后感","url":"/2021/12/31/聊聊最近平淡的生活之《花束般的恋爱》观后感/"},{"title":"聊聊这次换车牌及其他","url":"/2022/02/20/聊聊这次换车牌及其他/"}]
\ No newline at end of file
diff --git a/page/12/index.html b/page/12/index.html
index 5cdc3e24d7..686561e57b 100644
--- a/page/12/index.html
+++ b/page/12/index.html
@@ -26,7 +26,7 @@
         int queues = url.getParameter("queues", 0);
         int alive = url.getParameter("alive", 60000);
         return new ThreadPoolExecutor(cores, threads, (long)alive, TimeUnit.MILLISECONDS, (BlockingQueue)(queues == 0 ? new SynchronousQueue() : (queues < 0 ? new LinkedBlockingQueue() : new LinkedBlockingQueue(queues))), new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
-    }
这里可以看到线程池的配置，核心是 0，最大线程数是 2147483647，保活时间是一分钟
只是非常简略的介绍下，有兴趣可以自行阅读代码。
 发表于   分类于  ，  ，  ，  ，   阅读次数：   Disqus： 
拖更原因
这篇年终总结本来应该在农历过完年就出来的，结果是对没有受疫情影响的春节放假时间空闲情况预估太良好，虽然公司调了几天假，但是因为春节期间疫情状况比较好，本来酒店都不让接待聚餐什么的，后来统统放开，结果就是从初一到初六每天要不就是去亲戚家，要不就是去酒店饭店吃饭，计划很丰满，现实很骨感，时间感觉一下就没了，然后年后感觉有点犯懒了，所以才拖到现在。
生活-健身跑步
去年（19 年）的时候跑步突破了 300 公里，然后20 年给自己定了个 400 公里的目标，结果意料之中的没成功，原因可能疫情算一点吧，后面买了跑步机之后，基本周末回家都能跑一下，但是最后还是只跑了300 多公里，总的keep 记录跑量也没超过 1000 公里，所以跑步这个目标还是没成功的，不过还算是比去年多跑一点，这样也算后面好突破点，后面的目标就不定的太高了，每年能比前一年多一点就好，其实跑步已经从一种减肥方式变成一种习惯了，一周一次的跑步已经比较难有效减重了，但是对于保持精力和身体状态还是很有效和重要的，只是对于目前的体重还是要多减下去一些跑步才好，太重了对膝盖负担太大了，可惜还是时间呐，游泳骑车什么的都需要更苛刻的条件和时间，饮食呢控制起来比较难（贪吃
终于在 3 月底之前跑到了 1000 公里，迟了三个月，不过也总算达到了，只是体重控制还是不行，有试着走走楼梯，但是感觉对膝盖负担比较大，得再想想用什么方式
技术成长
一直提不起笔来写这篇年终总结还有个比较大的原因是觉得20 年的成长不如预期，大小目标都没怎么完成，比如深入了解 jvm，是想能有些深入的见解，而不再是某些点的比较片面的理解，系统性的归纳总结也比较少，每个方向或多或少有些看法和理解，但是不全面，一些东西看过了也会忘记，需要温故而知新，比如 AQS 的内容，第一次读其实理解比较浅，后面就强迫自己去读，去写，才有了一些比之前更深入的理解，因为很多文章都是带有作者思路的引导，适不适合自己都要看是否能从他的思路把它看懂，有些就差别很大，这个跟看书也一样，有些书大众一致推荐，一般情况下大多是经典的好的，但是也有可能是不太适合自己的，可能有时候机缘巧合看到的反而让人茅塞顿开，在 todo 里已经积攒了好多的点和面需要去学习实践，一方面是自己懒，一方面是时间也相对偏少，看看 21 年能不能有所提升，加强“时间管理”，哈哈
技术上主要是看了 mysql 的 mvcc 相关内容，rocketmq 的，redis 的代码，还有 mybatis 等，其实每一个都能写很多，也有很多值得学习的，需要全面系统学习，之前想好好画一个思维导图，将整个技术体系都梳理下，还只做了一点点，方式也有点问题，应该从大到小，而不是深度优先，细节有很多，每一个方面都有自己比较熟悉擅长的，也有不太了解的，可以做一个评分，这个也是亟待改善的，希望今年能完成。
博客
博客方面 20 年一年整是写了 53 篇，差不多是一周一篇的节奏，这个还是不错的，虽然博客质量参差不齐，但是这个更新频率还是比较好的，并且也定了个潜规则，可以一周技术一周生活，这样能缓解水文的频率，提高些技术文章的质量，虽然结果并没有好多少，不过感觉还是可以这么坚持的，能提高一些技术文章的质量那就更好了
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H  :Threads-mode operation
+    }
这里可以看到线程池的配置，核心是 0，最大线程数是 2147483647，保活时间是一分钟
只是非常简略的介绍下，有兴趣可以自行阅读代码。
 发表于   分类于  ，  ，  ，  ，   阅读次数：   Disqus： 
拖更原因
这篇年终总结本来应该在农历过完年就出来的，结果是对没有受疫情影响的春节放假时间空闲情况预估太良好，虽然公司调了几天假，但是因为春节期间疫情状况比较好，本来酒店都不让接待聚餐什么的，后来统统放开，结果就是从初一到初六每天要不就是去亲戚家，要不就是去酒店饭店吃饭，计划很丰满，现实很骨感，时间感觉一下就没了，然后年后感觉有点犯懒了，所以才拖到现在。
生活-健身跑步
去年（19 年）的时候跑步突破了 300 公里，然后20 年给自己定了个 400 公里的目标，结果意料之中的没成功，原因可能疫情算一点吧，后面买了跑步机之后，基本周末回家都能跑一下，但是最后还是只跑了300 多公里，总的keep 记录跑量也没超过 1000 公里，所以跑步这个目标还是没成功的，不过还算是比去年多跑一点，这样也算后面好突破点，后面的目标就不定的太高了，每年能比前一年多一点就好，其实跑步已经从一种减肥方式变成一种习惯了，一周一次的跑步已经比较难有效减重了，但是对于保持精力和身体状态还是很有效和重要的，只是对于目前的体重还是要多减下去一些跑步才好，太重了对膝盖负担太大了，可惜还是时间呐，游泳骑车什么的都需要更苛刻的条件和时间，饮食呢控制起来比较难（贪吃
终于在 3 月底之前跑到了 1000 公里，迟了三个月，不过也总算达到了，只是体重控制还是不行，有试着走走楼梯，但是感觉对膝盖负担比较大，得再想想用什么方式
技术成长
一直提不起笔来写这篇年终总结还有个比较大的原因是觉得20 年的成长不如预期，大小目标都没怎么完成，比如深入了解 jvm，是想能有些深入的见解，而不再是某些点的比较片面的理解，系统性的归纳总结也比较少，每个方向或多或少有些看法和理解，但是不全面，一些东西看过了也会忘记，需要温故而知新，比如 AQS 的内容，第一次读其实理解比较浅，后面就强迫自己去读，去写，才有了一些比之前更深入的理解，因为很多文章都是带有作者思路的引导，适不适合自己都要看是否能从他的思路把它看懂，有些就差别很大，这个跟看书也一样，有些书大众一致推荐，一般情况下大多是经典的好的，但是也有可能是不太适合自己的，可能有时候机缘巧合看到的反而让人茅塞顿开，在 todo 里已经积攒了好多的点和面需要去学习实践，一方面是自己懒，一方面是时间也相对偏少，看看 21 年能不能有所提升，加强“时间管理”，哈哈
技术上主要是看了 mysql 的 mvcc 相关内容，rocketmq 的，redis 的代码，还有 mybatis 等，其实每一个都能写很多，也有很多值得学习的，需要全面系统学习，之前想好好画一个思维导图，将整个技术体系都梳理下，还只做了一点点，方式也有点问题，应该从大到小，而不是深度优先，细节有很多，每一个方面都有自己比较熟悉擅长的，也有不太了解的，可以做一个评分，这个也是亟待改善的，希望今年能完成。
博客
博客方面 20 年一年整是写了 53 篇，差不多是一周一篇的节奏，这个还是不错的，虽然博客质量参差不齐，但是这个更新频率还是比较好的，并且也定了个潜规则，可以一周技术一周生活，这样能缓解水文的频率，提高些技术文章的质量，虽然结果并没有好多少，不过感觉还是可以这么坚持的，能提高一些技术文章的质量那就更好了
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H  :Threads-mode operation
             Instructs top to display individual threads.  Without this command-line option a summation of all threads in each process  is  shown.   Later
             this can be changed with the `H' interactive command.
这样就能用在 Java 中去 jstack 中找到对应的线程
其实还有比较重要的两个操作，
一个是在 top 启动状态下，按c键，这样能把比如说是一个 Java 进程，具体的进程命令显示出来
像这样
执行前是这样

执行后是这样

第二个就是排序了
SORTING of task window
 
diff --git a/page/17/index.html b/page/17/index.html
index d39bf9335a..ed343636a2 100644
--- a/page/17/index.html
+++ b/page/17/index.html
@@ -52,7 +52,7 @@ Output: [8,9,9,9,0,0,0,1]
 //        tail = null;
         return root;
-    }
这里唯二需要注意的就是两个点，一个是循环条件需要包含进位值还存在的情况，还有一个是最后一个节点，如果是空的了，就不要在 new 一个出来了，写的比较挫
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
Java 真的是任何一个中间件，比较常用的那种，都有很多内容值得深挖，比如这个缓存，慢慢有过一些感悟，比如如何提升性能，缓存无疑是一大重要手段，最底层开始 CPU 就有缓存，而且又小又贵，再往上一点内存一般作为硬盘存储在运行时的存储，一般在代码里也会用内存作为一些本地缓存，譬如数据库，像 mysql 这种也是有innodb_buffer_pool来提升查询效率，本质上理解就是用更快的存储作为相对慢存储的缓存，减少查询直接访问较慢的存储，并且这个都是相对的，比起 cpu 的缓存，那内存也是渣，但是与普通机械硬盘相比，那也是两个次元的水平。
闲扯这么多来说说 mybatis 的缓存，mybatis 一般作为一个轻量级的 orm 使用，相对应的就是比较重量级的 hibernate，不过不在这次讨论范围，上一次是主要讲了 mybatis 在解析 sql 过程中，对于两种占位符的不同替换实现策略，这次主要聊下 mybatis 的缓存，前面其实得了解下前置的东西，比如 sqlsession，先当做我们知道 sqlsession 是个什么玩意，可能或多或少的知道 mybatis 是有两级缓存，
一级缓存
第一级的缓存是在 BaseExecutor 中的 PerpetualCache，它是个最基本的缓存实现类，使用了 HashMap 实现缓存功能，代码其实没几十行
public class PerpetualCache implements Cache {
+    }
这里唯二需要注意的就是两个点，一个是循环条件需要包含进位值还存在的情况，还有一个是最后一个节点，如果是空的了，就不要在 new 一个出来了，写的比较挫
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
Java 真的是任何一个中间件，比较常用的那种，都有很多内容值得深挖，比如这个缓存，慢慢有过一些感悟，比如如何提升性能，缓存无疑是一大重要手段，最底层开始 CPU 就有缓存，而且又小又贵，再往上一点内存一般作为硬盘存储在运行时的存储，一般在代码里也会用内存作为一些本地缓存，譬如数据库，像 mysql 这种也是有innodb_buffer_pool来提升查询效率，本质上理解就是用更快的存储作为相对慢存储的缓存，减少查询直接访问较慢的存储，并且这个都是相对的，比起 cpu 的缓存，那内存也是渣，但是与普通机械硬盘相比，那也是两个次元的水平。
闲扯这么多来说说 mybatis 的缓存，mybatis 一般作为一个轻量级的 orm 使用，相对应的就是比较重量级的 hibernate，不过不在这次讨论范围，上一次是主要讲了 mybatis 在解析 sql 过程中，对于两种占位符的不同替换实现策略，这次主要聊下 mybatis 的缓存，前面其实得了解下前置的东西，比如 sqlsession，先当做我们知道 sqlsession 是个什么玩意，可能或多或少的知道 mybatis 是有两级缓存，
一级缓存
第一级的缓存是在 BaseExecutor 中的 PerpetualCache，它是个最基本的缓存实现类，使用了 HashMap 实现缓存功能，代码其实没几十行
public class PerpetualCache implements Cache {
 
   private final String id;
 
diff --git a/page/18/index.html b/page/18/index.html
index e6962cd389..42ed0bdba4 100644
--- a/page/18/index.html
+++ b/page/18/index.html
@@ -38,7 +38,7 @@ Output: 0
注释应该写的比较清楚了。
 发表于   分类于  ，  ，  ，   阅读次数：   Disqus： 
小工记三
前面这两周周末也都去老丈人家帮忙了，上上周周六先是去了那个在装修的旧房子那，把三楼收拾了下，因为要搬进来住，来不及等二楼装修好，就要把三楼里的东西都整理干净，这个活感觉是比较 easy，原来是就准备把三楼当放东西仓储的地方了，我们乡下大部分三层楼都是这么用的，这次也是没办法，之前搬进来的木头什么的都搬出去，主要是这上面灰尘太多，后面清理鼻孔的时候都是黑色的了，把东西都搬出去以后主要是地还是很脏，就扫了地拖了地，因为是水泥地，灰尘又太多了，拖起来都是会灰尘扬起来，整个脱完了的确干净很多，然而这会就出了个大乌龙，我们清理的是三楼的西边一间，结果老丈人上来说要住东边那间的🤦‍♂️，不过其实西边的也得清理，因为还是要放被子什么的，不算是白费功夫，接着清理东边那间，之前这个房子做过群租房，里面有个高低铺的床，当时觉得可以用在放被子什么的就没扔，只是拆掉了放旁边，我们就把它擦干净了又装好，发现螺丝🔩少了几个，亘古不变的真理，拆了以后装要不就多几个要不就少几个，不是很牢靠，不过用来放放被子省得放地上总还是可以的，对了前面还做了个事情就是铺地毯，其实也不是地毯，就是类似于墙布雨篷布那种，别人不用了送给我们的，三楼水泥地也不会铺瓷砖地板了就放一下，干净好看点，不过大小不合适要裁一下，那把剪刀是真的太难用了，我手都要抽筋了，它就是刀口只有一小个点是能剪下来的，其他都是钝的，后来还是用刀片直接裁，铺好以后，真的感觉也不太一样了，焕然一新的感觉
差不多中午了就去吃饭了，之前两次是去了一家小饭店，还是还比较干净，但是店里菜不好吃，还死贵，这次去了一家小快餐店，口味好，便宜，味道是真的不错，带鱼跟黄鱼都好吃，一点都不腥，我对这类比较腥的鱼真的是很挑剔的，基本上除了家里做的很少吃外面的，那天抱着试试的态度吃了下，真的还不错，后来丈母娘说好像这家老板是给别人结婚喜事酒席当厨师的，怪不得做的好吃，其实本来是有一点小抗拒，怕不干净什么的，后来发现菜很好吃，而且可能是老丈人跟干活的师傅去吃的比较多，老板很客气，我们吃完饭，还给我们买了葡萄吃，不过这家店有一个槽点，就是饭比较不好吃，有时候会夹生，不过后面聊起来其实是这种小菜馆饭点的通病，烧的太早太多容易多出来浪费，烧的迟了不够吃，而且大的电饭锅比较不容易烧好。
下午前面还是在处理三楼的，窗户上各种钉子，实在是太多了，我后面在走廊上排了一排🤦‍♂️，有些是直接断了，有些是就撬了出来，感觉我在杭州租房也没有这样子各种钉钉子，挂下衣服什么的也不用这么多吧，比较不能理解，搞得到处都是钉子。那天我爸也去帮忙了，主要是在卫生间里做白缝，其实也是个技术活，印象中好像我小时候自己家里也做过这个事情，但是比较模糊了，后面我们三楼搞完了就去帮我爸了，前面是我老婆二爹在那先刷上白缝，这里叫白缝，有些考究的也叫美缝，就是瓷砖铺完之后的缝，如果不去弄的话，里面水泥的颜色就露出来了，而且容易渗水，所以就要用白水泥加胶水搅拌之后糊在缝上，但是也不是直接糊，先要把缝抠一抠，因为铺瓷砖的还不会仔细到每个缝里的水泥都是一样满，而且也需要一些空间糊上去，不然就太表面的一层很容易被水直接冲掉了，然后这次其实也不是用的白水泥，而是直接现成买来就已经配好的用来填缝的，兑水搅拌均匀就好了，后面就主要是我跟我爸在搞，那个时候真的觉得我实在是太胖了，蹲下去真的没一会就受不了了，膝盖什么的太难受了，后面我跪着刷，然后膝盖又疼，也是比较不容易，不过我爸动作很快，我中间跪累了休息一会，我爸就能搞一大片，后面其实我也没做多少（谦虚一下），总体来讲这次不是很累，就是蹲着跪着腿有点受不了，是应该好好减肥了。
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条select * from t1 where id = #{id}这样的 sql，在初始化扫描 mapper 的xml文件的时候会根据是否是 dynamic 来判断生成 DynamicSqlSource 还是 RawSqlSource，这里它是一条 RawSqlSource，
在这里做了替换，将#{}替换成了?

前面说的是否 dynamic 就是在这里进行判断
// org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode
+}
注释应该写的比较清楚了。
 发表于   分类于  ，  ，  ，   阅读次数：   Disqus： 
小工记三
前面这两周周末也都去老丈人家帮忙了，上上周周六先是去了那个在装修的旧房子那，把三楼收拾了下，因为要搬进来住，来不及等二楼装修好，就要把三楼里的东西都整理干净，这个活感觉是比较 easy，原来是就准备把三楼当放东西仓储的地方了，我们乡下大部分三层楼都是这么用的，这次也是没办法，之前搬进来的木头什么的都搬出去，主要是这上面灰尘太多，后面清理鼻孔的时候都是黑色的了，把东西都搬出去以后主要是地还是很脏，就扫了地拖了地，因为是水泥地，灰尘又太多了，拖起来都是会灰尘扬起来，整个脱完了的确干净很多，然而这会就出了个大乌龙，我们清理的是三楼的西边一间，结果老丈人上来说要住东边那间的🤦‍♂️，不过其实西边的也得清理，因为还是要放被子什么的，不算是白费功夫，接着清理东边那间，之前这个房子做过群租房，里面有个高低铺的床，当时觉得可以用在放被子什么的就没扔，只是拆掉了放旁边，我们就把它擦干净了又装好，发现螺丝🔩少了几个，亘古不变的真理，拆了以后装要不就多几个要不就少几个，不是很牢靠，不过用来放放被子省得放地上总还是可以的，对了前面还做了个事情就是铺地毯，其实也不是地毯，就是类似于墙布雨篷布那种，别人不用了送给我们的，三楼水泥地也不会铺瓷砖地板了就放一下，干净好看点，不过大小不合适要裁一下，那把剪刀是真的太难用了，我手都要抽筋了，它就是刀口只有一小个点是能剪下来的，其他都是钝的，后来还是用刀片直接裁，铺好以后，真的感觉也不太一样了，焕然一新的感觉
差不多中午了就去吃饭了，之前两次是去了一家小饭店，还是还比较干净，但是店里菜不好吃，还死贵，这次去了一家小快餐店，口味好，便宜，味道是真的不错，带鱼跟黄鱼都好吃，一点都不腥，我对这类比较腥的鱼真的是很挑剔的，基本上除了家里做的很少吃外面的，那天抱着试试的态度吃了下，真的还不错，后来丈母娘说好像这家老板是给别人结婚喜事酒席当厨师的，怪不得做的好吃，其实本来是有一点小抗拒，怕不干净什么的，后来发现菜很好吃，而且可能是老丈人跟干活的师傅去吃的比较多，老板很客气，我们吃完饭，还给我们买了葡萄吃，不过这家店有一个槽点，就是饭比较不好吃，有时候会夹生，不过后面聊起来其实是这种小菜馆饭点的通病，烧的太早太多容易多出来浪费，烧的迟了不够吃，而且大的电饭锅比较不容易烧好。
下午前面还是在处理三楼的，窗户上各种钉子，实在是太多了，我后面在走廊上排了一排🤦‍♂️，有些是直接断了，有些是就撬了出来，感觉我在杭州租房也没有这样子各种钉钉子，挂下衣服什么的也不用这么多吧，比较不能理解，搞得到处都是钉子。那天我爸也去帮忙了，主要是在卫生间里做白缝，其实也是个技术活，印象中好像我小时候自己家里也做过这个事情，但是比较模糊了，后面我们三楼搞完了就去帮我爸了，前面是我老婆二爹在那先刷上白缝，这里叫白缝，有些考究的也叫美缝，就是瓷砖铺完之后的缝，如果不去弄的话，里面水泥的颜色就露出来了，而且容易渗水，所以就要用白水泥加胶水搅拌之后糊在缝上，但是也不是直接糊，先要把缝抠一抠，因为铺瓷砖的还不会仔细到每个缝里的水泥都是一样满，而且也需要一些空间糊上去，不然就太表面的一层很容易被水直接冲掉了，然后这次其实也不是用的白水泥，而是直接现成买来就已经配好的用来填缝的，兑水搅拌均匀就好了，后面就主要是我跟我爸在搞，那个时候真的觉得我实在是太胖了，蹲下去真的没一会就受不了了，膝盖什么的太难受了，后面我跪着刷，然后膝盖又疼，也是比较不容易，不过我爸动作很快，我中间跪累了休息一会，我爸就能搞一大片，后面其实我也没做多少（谦虚一下），总体来讲这次不是很累，就是蹲着跪着腿有点受不了，是应该好好减肥了。
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条select * from t1 where id = #{id}这样的 sql，在初始化扫描 mapper 的xml文件的时候会根据是否是 dynamic 来判断生成 DynamicSqlSource 还是 RawSqlSource，这里它是一条 RawSqlSource，
在这里做了替换，将#{}替换成了?

前面说的是否 dynamic 就是在这里进行判断
// org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode
 public SqlSource parseScriptNode() {
     MixedSqlNode rootSqlNode = parseDynamicTags(context);
     SqlSource sqlSource;
diff --git a/page/19/index.html b/page/19/index.html
index 5bc612c156..2aa9065e41 100644
--- a/page/19/index.html
+++ b/page/19/index.html
@@ -1,4 +1,4 @@
-Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
 发表于   分类于  ，  ，  ，   阅读次数：   Disqus： 
这周回家提前约好了要去老丈人家帮下忙，因为在翻修下老房子，活不是特别整的那种，所以大部分都是自己干，或者找个大工临时干几天（我们这那种比较专业的泥工匠叫做大工），像我这样去帮忙的，就是干点小工（把给大工帮忙的，干些偏体力活的叫做小工）的活。从大学毕业以后真的蛮少帮家里干活了，以前上学的时候放假还是帮家里淘个米，简单的扫地拖地啥的，当然刚高考完的时候，还去我爸厂里帮忙干了几天的活，实在是比较累，不过现在想着是觉得自己那时候比较牛，而不是特别排斥这个活，相对于现在的工作来说，导致了一系列的职业病，颈椎腰背都很僵硬，眼镜也不好，还有反流，像我爸那种活反而是脑力加体力的比较好的结合。
这一天的活前半部分主要是在清理厨房，瓷砖上的油污和墙上天花板上即将脱落的石灰或者白色涂料层，这种活特别是瓷砖上的油污，之前在自己家里也干活，还是比较熟悉的，不过前面主要是LD 在干，我主要是先搞墙上和天花板上的，干活还是很需要技巧的，如果直接去铲，那基本我会变成一个灰人，而且吸一鼻子灰，老丈人比较专业，先接上软管用水冲，一冲效果特别好，有些石灰涂料层直接就冲掉了，冲完之后先用带加长杆的刀片铲铲了一圈墙面，说实话因为老房子之前租出去了，所以墙面什么的被糟蹋的比较难看，一层一层的，不过这还算还好，后面主要是天花板上的，这可难倒我了，从小我爸妈是比较把我当小孩管着，爬上爬下的基本都是我爸搞定，但是到了老丈人家也只得硬着头皮上了，爬到跳（一种建筑工地用的架子）上，还有点晃，小心脏扑通扑通跳，而且带加长杆的铲子还是比较重的，铲一会手也有点累，不过坚持着铲完了，上面还是比较平整的，不过下来的时候又把我难住了🤦‍♂️，往下爬的时候有根杆子要跨过去，由于裤子比较紧，强行一把跨过去怕抽筋，所以以一个非常尴尬的姿势停留休息了一会，再跨了过去，幸好事后问 LD，他们都没看到，哈哈哈，然后就是帮忙一起搞瓷砖上的油污，这个太有经验了，不过老丈人更有意思，一会试试啤酒，一会用用沙子，后面在午饭前基本就弄的比较干净了，就坐着等吃饭了，下午午休了会，就继续干活了。
下午是我这次体验的重点了，因为要清理以前贴的墙纸，真的是个很麻烦的活，只能说贴墙纸的师傅活干得太好了，基本不可能整个撕下来，想用铲子一点点铲下来也不行，太轻了就只铲掉表面一层，太重了就把墙纸跟墙面的石灰啥的整个铲下来了，而且手又累又酸，后来想着是不是继续用水冲一下，对着一小面墙试验了下，效果还不错，但是又发现了个问题，那一面墙又有一块是后面糊上去的，铲掉外层的石灰后不平，然后就是最最重头的，也是让我后遗症持续到第二天的，要把那一块糊上去的水泥敲下来，毛估下大概是敲了80%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，
譬如

+Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
 发表于   分类于  ，  ，  ，   阅读次数：   Disqus： 
这周回家提前约好了要去老丈人家帮下忙，因为在翻修下老房子，活不是特别整的那种，所以大部分都是自己干，或者找个大工临时干几天（我们这那种比较专业的泥工匠叫做大工），像我这样去帮忙的，就是干点小工（把给大工帮忙的，干些偏体力活的叫做小工）的活。从大学毕业以后真的蛮少帮家里干活了，以前上学的时候放假还是帮家里淘个米，简单的扫地拖地啥的，当然刚高考完的时候，还去我爸厂里帮忙干了几天的活，实在是比较累，不过现在想着是觉得自己那时候比较牛，而不是特别排斥这个活，相对于现在的工作来说，导致了一系列的职业病，颈椎腰背都很僵硬，眼镜也不好，还有反流，像我爸那种活反而是脑力加体力的比较好的结合。
这一天的活前半部分主要是在清理厨房，瓷砖上的油污和墙上天花板上即将脱落的石灰或者白色涂料层，这种活特别是瓷砖上的油污，之前在自己家里也干活，还是比较熟悉的，不过前面主要是LD 在干，我主要是先搞墙上和天花板上的，干活还是很需要技巧的，如果直接去铲，那基本我会变成一个灰人，而且吸一鼻子灰，老丈人比较专业，先接上软管用水冲，一冲效果特别好，有些石灰涂料层直接就冲掉了，冲完之后先用带加长杆的刀片铲铲了一圈墙面，说实话因为老房子之前租出去了，所以墙面什么的被糟蹋的比较难看，一层一层的，不过这还算还好，后面主要是天花板上的，这可难倒我了，从小我爸妈是比较把我当小孩管着，爬上爬下的基本都是我爸搞定，但是到了老丈人家也只得硬着头皮上了，爬到跳（一种建筑工地用的架子）上，还有点晃，小心脏扑通扑通跳，而且带加长杆的铲子还是比较重的，铲一会手也有点累，不过坚持着铲完了，上面还是比较平整的，不过下来的时候又把我难住了🤦‍♂️，往下爬的时候有根杆子要跨过去，由于裤子比较紧，强行一把跨过去怕抽筋，所以以一个非常尴尬的姿势停留休息了一会，再跨了过去，幸好事后问 LD，他们都没看到，哈哈哈，然后就是帮忙一起搞瓷砖上的油污，这个太有经验了，不过老丈人更有意思，一会试试啤酒，一会用用沙子，后面在午饭前基本就弄的比较干净了，就坐着等吃饭了，下午午休了会，就继续干活了。
下午是我这次体验的重点了，因为要清理以前贴的墙纸，真的是个很麻烦的活，只能说贴墙纸的师傅活干得太好了，基本不可能整个撕下来，想用铲子一点点铲下来也不行，太轻了就只铲掉表面一层，太重了就把墙纸跟墙面的石灰啥的整个铲下来了，而且手又累又酸，后来想着是不是继续用水冲一下，对着一小面墙试验了下，效果还不错，但是又发现了个问题，那一面墙又有一块是后面糊上去的，铲掉外层的石灰后不平，然后就是最最重头的，也是让我后遗症持续到第二天的，要把那一块糊上去的水泥敲下来，毛估下大概是敲了80%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。
 发表于   分类于  ，  ，  ，  ，  ，   阅读次数：   Disqus： 
用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，
譬如

 grep 'xxx' xxxx.log
 
然后有挺多情况比如想要找日志里带一些符号什么的，就需要用到一些特殊的
比如这样\"userId\":\"123456\"，因为比如用户 ID 有时候会跟其他的 id 一样，只用具体的值 123456 来查的话干扰信息太多了，如果直接这样

 grep '\"userId\":\"123456\"' xxxx.log
diff --git a/search.xml b/search.xml
index ed45c183bd..f461ac96ce 100644
--- a/search.xml
+++ b/search.xml
@@ -1,25 +1,5 @@
 
 
-  
-    村上春树《1Q84》读后感
-    /2019/12/18/1Q84%E8%AF%BB%E5%90%8E%E6%84%9F/
-    看完了村上春树的《1Q84》，这应该是第五本看的他的书了，继 跑步，挪威的森林，刺杀骑士团长，海边的卡夫卡之后，不是其中最长的，好像是海边的卡夫卡还是刺杀骑士团长比较长一点，都是在微信读书上看的，比较方便，最开始在上面看的是高晓松的《鱼羊野史》，不知道为啥取这个名字，但是还是满吸引我的，不过由于去年的种种，没有很多心思把它看完，而且本身的组织形式就是比较松散的，看到哪算哪，其实一些野史部分是我比较喜欢，有些谈到人物的就不太有兴趣，而且类似于大祥哥吃的东西，反正都是哇，怎么这么好吃，嗯，太爱（niu）你（bi）了，高晓松就是这个人是我最喜欢的 xxx 家，我也没去细究过他有没有说重复过，反正是不太爱，后来因为这书还一度对战争史有了浓厚的兴趣，然而事实告诉我，大部头的战争史，其实正史我是真的啃不下去，我可能只对其中 10%的内容感兴趣，不过终于也在今年把它看完了，好像高晓松的晓说也最终季了，貌似其中讲朝鲜战争的还被和谐了，看样子是说出了一些故事（truth）。

-
本来只是想把 《1Q84》的读后感写下，现在觉得还是把这篇当成我今年的读书总结吧，不过先从《1Q84》说起。

-
严格来讲，这不是很书面化的读后感，可能我想写的也只是像聊天一样的说下我读过的书，包括的技术博客其实也是类似的，以后或许会转变，但是目前水平如此吧，写多了可能会变好，也可能不会。

-
开始正文吧，这书有点类似于海边的卡夫卡，一开始是通过两条故事线，穿插着叙述，一条是青豆的，不算是个职业杀手的女杀手，要去解决一个经常家暴的斯文败类，穿着描述得比较性感吧，杀人方式是通过比较长的细针，从脖子后面一个精巧的位置插入，可以造成是未知原因死亡的假象，可能会推断成心梗之类的，这里有个前置的细节，就是青豆是乘坐一辆很高级的出租车，内饰什么的都非常有质感，有点不像一辆出租车，然后车里放了一首比较小众的歌，雅纳切克的《小交响曲》，但是青豆知道它，这跟后面的情节也有些许关系，这是女主人公青豆的出场；相应的男主的出场印象不是太深刻，男主叫天吾，是个不知名的作家，跟一个叫小松的编辑有比较好的关系，虽然天吾还没有拿到比较有分量的奖项，但是小松很看好他，也让他帮忙审校一个新作家奖的投稿文章，虽然天吾自身还没获得过这个奖，天吾还有个正式工作，是当数学老师，天吾在学生时代是个数学天才，但后面有对文学产生了兴趣，文学还不足以养活自己，靠着教课还是能保持温饱；

-
接下来是正式故事的起点了，就是小松收到了一部小说投稿，名叫《空气蛹》，是个叫深绘里的女孩子投的稿，小松对他赋予了很高的评价，这里好像记岔了，好像是天吾对这部小说很有好感，但是小松比较怀疑，然后小松看了之后也有了浓厚的兴趣，这里就是开端了，小松想让天吾来重写润色这部《空气蛹》，因为故事本身很有分量，但是描写手法叙事方式等都很拙劣，而天吾正好擅长这个，小松对天吾的评价是，描写技巧无可挑剔，就是故事主体的火花还没际遇迸发，需要一个导火索，这个就可以类比我们程序员，很多比较初中级的程序员主要擅长在原来的代码上修修改改或者给他分配个小功能，比较高级的程序员就需要能做一些项目的架构设计，核心的技术方案设计，以前我也觉得写文档这个比较无聊，但是当一个项目真的比较庞大，复杂的时候，整体和核心部分的架构设计和方案还是需要有文档沉淀的，不然别人不知道没法接受，自己过段时间也会忘记。

-
对于小松的这个建议，他的初衷是想搅一搅这个死气沉沉套路颇深的文坛，因为本身《空气蛹》这部小说的内容很吸引人，小松想通过天吾的润色补充让这部小说冲击新人奖，有种恶作剧的意图，天吾对此表示很多担心和顾虑，小松的这个建议其实也是一种文学作假，有两方面的担心，一方面是原作者深绘里是否同意如此操作，一方面是外界如果发现了这个事实会有什么样的后果，但是小松表示不用担心，前一步由小松牵线，让天吾跟原作者深绘里当面沟通这个代写是否被允许，结果当然是被允许了，这里有了对深绘里的初步描写，按我的理解是比较仙的感觉，然后语言沟通有些吃力，或者说有她自己的特色，当面沟通时貌似是让深绘里回去再考虑下，然后后面再由天吾去深绘里寄宿的戎野老师家沟通具体的细节。

-
2019年12月18日23:37:19 更新
去到戎野老师家之后，天吾知道了关于深绘里的一些事情，深绘里的父亲与戎野老师应该是老友，深绘里的父亲在当初成立了一个叫”先驱”的公社，一个独立运行的社会组织，以运营农场作为物资来源，追求更为松散的共同体，即不过分激进地公有制，进行松散的共同生活，承认私有财产，简而言之就是这样一个能稳定存活下来的独立社会组织，但是随着稳定运行，内部的激进派和稳健派开始出现分歧，不可磨合，后来两派就分裂了，深绘里的父亲，深田保留在了稳健派，但是此时其实深田保内心是矛盾的，以为一开始其实是他倡导的独立革命才组织起了这群人，然而现在他又认清了现实社会已经不太相信能通过革命来独立的可能性，后来激进派便开始越加封闭，而且进行军事训练和思想教育，而后这个先驱的激进派别便有了新的名字”黎明”，深绘里也是在此时从先驱逃离来投靠戎野老师
暂时先写到这，未完待续~

-]]>
-      
-        生活
-        读后感
-        村上春树
-      
-      
-        读后感
-      
-  
   
     2019年终总结
     /2020/02/01/2019%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
@@ -75,62 +55,42 @@
       
   
   
-    2020年中总结
-    /2020/07/11/2020%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
-    很快2020 年就过了一半了，而且是今年这么特殊的一年，很多事情都发生的出乎意料，疫情这个绕不过去的话题，之前写了点比较愤青的文字，感觉不太适合发出来就烂在草稿箱里吧，这个目前一大影响估计是今年都没办法完全摘下口罩了，前面几个月来回杭州都开车，因为彭埠大桥不通行了，实在是非常不方便，每条路都灰常堵，心累，吐槽下杭州的交通规划和交警同志，工作实在做的不咋地。

-
另外一件是就是蜗壳，从前不知道黝黑蜗壳是啥意思，只是经常会在他的视频里看到，大学的时候在缘网下了一个集锦，炒鸡帅气，各种空接扣篮，越来越能明白那句“你永远不知道意外和明天不知道哪个会先来,且行且珍惜”的含义，只是听了很多道理，依然活不好这一生，知易行难，王阳明真的是这方面的大师，有空可以看看这方面的书，一直想写写我跟篮球跟蜗壳的这十几年，争取能早日写好吧，不过得找个静得下来的时候写。

-
正事方面上半年还是挺让人失望的，没有达成一些目标，应该还是能力不足吧，技术方面分析一下还是停留在看的表面层，有些实操的，或者结合业务场景的能力不太行，算是在坚持写写 blog，主要是被这个每周一篇的目标推着走，有时会比较焦虑，内容产出也还比较差，希望能在后面有些改善，可能会降低频率，只是觉得降低了也不一定能有比较好的提升，无法战胜自己的惰性，所以暂时还是坚持下这个目标吧，还有就是 coding 能力，有时候也应该刷刷题，提升思维敏捷度，大脑用太少可能生锈了，况且本来就不是很有优势，虽然失望也只能继续努力吧，日拱一卒，来日方长，加油吧~😔

-
还有就是跑步减肥了，截止今天，上半年跑了 136 公里了，因为疫情影响，农历年后是从 4 月 17 号开始跑的，去年跑到了 300 公里，奖励自己了一个手表（真的挺后悔的，还不如 200 块买个手表），今年希望可以能在这个基础上再进一步，一直跟领导说，跑步算是我坚持下来的唯一一个好习惯了，618 买了个跑步机，周末回家了可以不受天气影响的多跑跑，不过如果天气好可能还是会出去跑跑，跑步机跑道多少还是有点拘束，只是感觉可能是我还是吃得太多了🤦‍♂️，效果不是很明显，还在 80 这个坎徘徊，等于浪费了大半年，可能是年初的项目太费心力，压力比较大，吃得更多，是不是可以算工伤😄，这方面也需要好好调整，可以放得开一点，虽然不太可能一下子到位，但是总要去努力下，随着年龄成长总要承担更多，也要看得开一点，没法事事如愿，尽力就好了，减肥这个事情还在结合一些俯卧撑啥的，希望也能坚持下去，加油吧，不知道原话怎么说的，意思是人类最大的勇敢就是看透了人世间的苦难，仍然热爱生活。我当然没可能让内心变得这么强大，试着去努力吧，奥力给！

+    村上春树《1Q84》读后感
+    /2019/12/18/1Q84%E8%AF%BB%E5%90%8E%E6%84%9F/
+    看完了村上春树的《1Q84》，这应该是第五本看的他的书了，继 跑步，挪威的森林，刺杀骑士团长，海边的卡夫卡之后，不是其中最长的，好像是海边的卡夫卡还是刺杀骑士团长比较长一点，都是在微信读书上看的，比较方便，最开始在上面看的是高晓松的《鱼羊野史》，不知道为啥取这个名字，但是还是满吸引我的，不过由于去年的种种，没有很多心思把它看完，而且本身的组织形式就是比较松散的，看到哪算哪，其实一些野史部分是我比较喜欢，有些谈到人物的就不太有兴趣，而且类似于大祥哥吃的东西，反正都是哇，怎么这么好吃，嗯，太爱（niu）你（bi）了，高晓松就是这个人是我最喜欢的 xxx 家，我也没去细究过他有没有说重复过，反正是不太爱，后来因为这书还一度对战争史有了浓厚的兴趣，然而事实告诉我，大部头的战争史，其实正史我是真的啃不下去，我可能只对其中 10%的内容感兴趣，不过终于也在今年把它看完了，好像高晓松的晓说也最终季了，貌似其中讲朝鲜战争的还被和谐了，看样子是说出了一些故事（truth）。

+
本来只是想把 《1Q84》的读后感写下，现在觉得还是把这篇当成我今年的读书总结吧，不过先从《1Q84》说起。

+
严格来讲，这不是很书面化的读后感，可能我想写的也只是像聊天一样的说下我读过的书，包括的技术博客其实也是类似的，以后或许会转变，但是目前水平如此吧，写多了可能会变好，也可能不会。

+
开始正文吧，这书有点类似于海边的卡夫卡，一开始是通过两条故事线，穿插着叙述，一条是青豆的，不算是个职业杀手的女杀手，要去解决一个经常家暴的斯文败类，穿着描述得比较性感吧，杀人方式是通过比较长的细针，从脖子后面一个精巧的位置插入，可以造成是未知原因死亡的假象，可能会推断成心梗之类的，这里有个前置的细节，就是青豆是乘坐一辆很高级的出租车，内饰什么的都非常有质感，有点不像一辆出租车，然后车里放了一首比较小众的歌，雅纳切克的《小交响曲》，但是青豆知道它，这跟后面的情节也有些许关系，这是女主人公青豆的出场；相应的男主的出场印象不是太深刻，男主叫天吾，是个不知名的作家，跟一个叫小松的编辑有比较好的关系，虽然天吾还没有拿到比较有分量的奖项，但是小松很看好他，也让他帮忙审校一个新作家奖的投稿文章，虽然天吾自身还没获得过这个奖，天吾还有个正式工作，是当数学老师，天吾在学生时代是个数学天才，但后面有对文学产生了兴趣，文学还不足以养活自己，靠着教课还是能保持温饱；

+
接下来是正式故事的起点了，就是小松收到了一部小说投稿，名叫《空气蛹》，是个叫深绘里的女孩子投的稿，小松对他赋予了很高的评价，这里好像记岔了，好像是天吾对这部小说很有好感，但是小松比较怀疑，然后小松看了之后也有了浓厚的兴趣，这里就是开端了，小松想让天吾来重写润色这部《空气蛹》，因为故事本身很有分量，但是描写手法叙事方式等都很拙劣，而天吾正好擅长这个，小松对天吾的评价是，描写技巧无可挑剔，就是故事主体的火花还没际遇迸发，需要一个导火索，这个就可以类比我们程序员，很多比较初中级的程序员主要擅长在原来的代码上修修改改或者给他分配个小功能，比较高级的程序员就需要能做一些项目的架构设计，核心的技术方案设计，以前我也觉得写文档这个比较无聊，但是当一个项目真的比较庞大，复杂的时候，整体和核心部分的架构设计和方案还是需要有文档沉淀的，不然别人不知道没法接受，自己过段时间也会忘记。

+
对于小松的这个建议，他的初衷是想搅一搅这个死气沉沉套路颇深的文坛，因为本身《空气蛹》这部小说的内容很吸引人，小松想通过天吾的润色补充让这部小说冲击新人奖，有种恶作剧的意图，天吾对此表示很多担心和顾虑，小松的这个建议其实也是一种文学作假，有两方面的担心，一方面是原作者深绘里是否同意如此操作，一方面是外界如果发现了这个事实会有什么样的后果，但是小松表示不用担心，前一步由小松牵线，让天吾跟原作者深绘里当面沟通这个代写是否被允许，结果当然是被允许了，这里有了对深绘里的初步描写，按我的理解是比较仙的感觉，然后语言沟通有些吃力，或者说有她自己的特色，当面沟通时貌似是让深绘里回去再考虑下，然后后面再由天吾去深绘里寄宿的戎野老师家沟通具体的细节。

+
2019年12月18日23:37:19 更新
去到戎野老师家之后，天吾知道了关于深绘里的一些事情，深绘里的父亲与戎野老师应该是老友，深绘里的父亲在当初成立了一个叫”先驱”的公社，一个独立运行的社会组织，以运营农场作为物资来源，追求更为松散的共同体，即不过分激进地公有制，进行松散的共同生活，承认私有财产，简而言之就是这样一个能稳定存活下来的独立社会组织，但是随着稳定运行，内部的激进派和稳健派开始出现分歧，不可磨合，后来两派就分裂了，深绘里的父亲，深田保留在了稳健派，但是此时其实深田保内心是矛盾的，以为一开始其实是他倡导的独立革命才组织起了这群人，然而现在他又认清了现实社会已经不太相信能通过革命来独立的可能性，后来激进派便开始越加封闭，而且进行军事训练和思想教育，而后这个先驱的激进派别便有了新的名字”黎明”，深绘里也是在此时从先驱逃离来投靠戎野老师
暂时先写到这，未完待续~

 ]]>
       
         生活
-        年中总结
-        2020
+        读后感
+        村上春树
       
       
-        生活
-        2020
-        年中总结
+        读后感
       
   
   
-    2021 年中总结
-    /2021/07/18/2021-%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
-    又到半年总结时，第一次写总结类型的文章感觉挺好写的，但是后面总觉得这过去的一段时间所做的事情，能力上的成长低于预期，但是是需要总结下，找找问题，顺便展望下未来。

-
这一年做的最让自己满意的应该就是看了一些书，由折腾群洋总发起的读书打卡活动，到目前为止已经读完了这几本书，《cUrl 必知必会》，《古董局中局 1》，《古董局中局 2》，《算法图解》，《每天 5 分钟玩转 Kubernetes》《幸福了吗？》《高可用可伸缩微服务架构：基于 Dubbo、Spring Cloud和 Service Mesh》《Rust 权威指南》后面可以写个专题说说看的这些书，虽然每天打卡如果时间安排不好，并且看的书像 rust 这样比较难的话还是会有点小焦虑，不过也是个调整过程，一方面可以在白天就抽空看一会，然后也不必要每次都看很大一章，注重吸收。

-
技术上的成长的话，有一些比较小的长进吧，对于一些之前忽视的 synchronized，ThreadLocal 和 AQS 等知识点做了下查漏补缺了，然后多了解了一些 Java 垃圾回收的内容，但是在实操上还是比较欠缺，成型的技术方案，架构上所谓的优化也比较少，一些想法也还有考虑不周全的地方，还需要多花时间和心思去学习加强，特别是在目前已经有的基础上如何做系统深层次的优化，既不要是鸡毛蒜皮的，也不能出现一些不可接受的问题和故障，这是个很重要的课题，需要好好学习，后面考虑定一些周期性目标，两个月左右能有一些成果和总结。

-
另外一部分是自己的服务，因为 ucloud 的机器太贵就没续费了，所以都迁移到腾讯云的小机器上了，顺便折腾了一点点 traefik，但是还很不熟练，不太习惯这一套，一方面是 docker 还不习惯，这也加重了对这套环境的不适应，还是习惯裸机部署，另一方面就是 k8s 了，家里的机器还没虚拟化，没有很好的条件可以做实验，这也是读书打卡的一个没做好的点，整体的学习效果受限于深度和实操，后面是看都是用 traefik，也找到了一篇文章可以 traefik 转发到裸机应用，因为主仓库用的是裸机的 gogs。

-
还有就是运动减肥上，唉，这又是很大的一个痛点，基本没效果，只是还算稳定，昨天看到一个视频说还需要力量训练来增肌，以此可以提升基础代谢，打算往这个方向尝试下，因为今天没有疫情限制了，在 6 月底完成了 200 公里的跑步小目标，只是有些膝盖跟大腿根外侧不适，抽空得去看下医生，后面打算每天也能做点卷腹跟俯卧撑。

-
下半年还希望能继续多看看书，比很多网上各种乱七八糟的文章会好很多，结合豆瓣评分，找一些评价高一些的文章，但也不是说分稍低点的就不行，有些也看人是不是适合，一般 6 分以上评价比较多的就可以试试。

+    2020年中总结
+    /2020/07/11/2020%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
+    很快2020 年就过了一半了，而且是今年这么特殊的一年，很多事情都发生的出乎意料，疫情这个绕不过去的话题，之前写了点比较愤青的文字，感觉不太适合发出来就烂在草稿箱里吧，这个目前一大影响估计是今年都没办法完全摘下口罩了，前面几个月来回杭州都开车，因为彭埠大桥不通行了，实在是非常不方便，每条路都灰常堵，心累，吐槽下杭州的交通规划和交警同志，工作实在做的不咋地。

+
另外一件是就是蜗壳，从前不知道黝黑蜗壳是啥意思，只是经常会在他的视频里看到，大学的时候在缘网下了一个集锦，炒鸡帅气，各种空接扣篮，越来越能明白那句“你永远不知道意外和明天不知道哪个会先来,且行且珍惜”的含义，只是听了很多道理，依然活不好这一生，知易行难，王阳明真的是这方面的大师，有空可以看看这方面的书，一直想写写我跟篮球跟蜗壳的这十几年，争取能早日写好吧，不过得找个静得下来的时候写。

+
正事方面上半年还是挺让人失望的，没有达成一些目标，应该还是能力不足吧，技术方面分析一下还是停留在看的表面层，有些实操的，或者结合业务场景的能力不太行，算是在坚持写写 blog，主要是被这个每周一篇的目标推着走，有时会比较焦虑，内容产出也还比较差，希望能在后面有些改善，可能会降低频率，只是觉得降低了也不一定能有比较好的提升，无法战胜自己的惰性，所以暂时还是坚持下这个目标吧，还有就是 coding 能力，有时候也应该刷刷题，提升思维敏捷度，大脑用太少可能生锈了，况且本来就不是很有优势，虽然失望也只能继续努力吧，日拱一卒，来日方长，加油吧~😔

+
还有就是跑步减肥了，截止今天，上半年跑了 136 公里了，因为疫情影响，农历年后是从 4 月 17 号开始跑的，去年跑到了 300 公里，奖励自己了一个手表（真的挺后悔的，还不如 200 块买个手表），今年希望可以能在这个基础上再进一步，一直跟领导说，跑步算是我坚持下来的唯一一个好习惯了，618 买了个跑步机，周末回家了可以不受天气影响的多跑跑，不过如果天气好可能还是会出去跑跑，跑步机跑道多少还是有点拘束，只是感觉可能是我还是吃得太多了🤦‍♂️，效果不是很明显，还在 80 这个坎徘徊，等于浪费了大半年，可能是年初的项目太费心力，压力比较大，吃得更多，是不是可以算工伤😄，这方面也需要好好调整，可以放得开一点，虽然不太可能一下子到位，但是总要去努力下，随着年龄成长总要承担更多，也要看得开一点，没法事事如愿，尽力就好了，减肥这个事情还在结合一些俯卧撑啥的，希望也能坚持下去，加油吧，不知道原话怎么说的，意思是人类最大的勇敢就是看透了人世间的苦难，仍然热爱生活。我当然没可能让内心变得这么强大，试着去努力吧，奥力给！

 ]]>
       
         生活
         年中总结
-        2021
+        2020
       
       
         生活
-        2021
+        2020
         年中总结
-        技术
-        读书
-      
-  
-  
-    2021 年终总结
-    /2022/01/22/2021-%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
-    又是一年年终总结，本着极度讨厌实时需求的理念，我还是 T+N 发布这个年终总结

-
工作篇
工作没什么大变化，有了些微的提升，可能因为是来了之后做了些项目对比公司与来还算是比较重要的，但是技术难度上没有特别突出的点，可能最开始用 openresty+lua 做了个 ab 测的工具，还是让我比较满意的，后面一般都是业务型的需求，今年可能在业务相关的技术逻辑上有了一些深度的了解，而原来一直想做的业务架构升级和通用型技术中间件这样的优化还是停留在想象中，前面说的 ab 测应该算是个半成品，还是没能多走出这一步，得需要多做一些实在的事情，比如轻量级的业务框架，能够对原先不熟悉的业务逻辑，代码逻辑有比较深入的理解，而不是一直都是让特定的同学负责特定的逻辑，很多时候还是在偷懒，习惯以一些简单安全的方案去做事情，在技术上还是要有所追求，还有就是能够在新语言，主要是 rust，swift 这类的能有些小玩具可以做，rust 的话是因为今年看了一本相关的书，后面三分之一其实消化得不好，这本书整体来说是很不错的，只是 rust 本身在所有权这块，还有引用包装等方面是设计得比较难懂，也可能是我基础差，所以还是想在复习下，可以做一个简单的命令行工具这种，然后 swift 是想说可以做点 mac 的小软件，原生的毕竟性能好点，又小。基于 web 做的客户端大部分都是又丑又大，极少数能好看点，但也是很重，起码 7~80M 的大小，原生的估计能除以 10。
整体的职业规划貌似陷入了比较大的困惑期，在目前公司发展前景不是很大，但是出去貌似也没有比较适合我的机会，总的来说还是杭州比较卷，个人觉得有自己的时间是非常重要的，而且这个不光是用来自我提升的，还是让自己有足够的时间做缓冲，有足够的时间锻炼减肥，时间少的情况下，不光会在仅有的时间里暴饮暴食，还没空锻炼，身体是革命的本钱，现在其实能特别明显地感觉到身体状态下滑，容易疲劳，焦虑。所以是否也许有可能以后要往外企这类的方向去发展。
工作上其实还是有个不大不小的缺点，就是容易激动，容易焦虑，前一点可能有稍稍地改观，因为工作中的很多现状其实是我个人难以改变的，即使觉得不合理，但是结构在那里，还不如自己放宽心，尽量做好事情就行。第二点的话还是做得比较差，一直以来抗压能力都比较差，跟成长环境，家庭环境都有比较大的关系，而且说实在的特别是父母，基本也没有在这方面给我正向的帮助，比较擅长给我施压，从小就是通过压力让我好好读书，当个乖学生，考个好学校，并没有能真正地理解我的压力，教我或者帮助我解压，只会在那说着不着边际的空话，甚至经常反过来对我施压。还是希望能慢慢解开，这点可能对我身体也有影响，也许需要看一些心理疏导相关的书籍。工作篇暂时到这，后续还有其他篇，未完待续哈哈😀

-]]>
-      
-        生活
-        年终总结
-      
-      
-        生活
-        年终总结
-        2021
-        拖更
       
   
   
@@ -677,271 +637,66 @@ public:
       
   
   
-    AQS篇一
-    /2021/02/14/AQS%E7%AF%87%E4%B8%80/
-    很多东西都是时看时新，而且时间长了也会忘，所以再来复习下，也会有一些新的角度看法这次来聊下AQS的内容，主要是这几个点，

-
第一个线程
第一个线程抢到锁了，此时state跟阻塞队列是怎么样的，其实这里是之前没理解对的地方

-
/**
-         * Fair version of tryAcquire.  Don't grant access unless
-         * recursive call or no waiters or is first.
-         */
-        protected final boolean tryAcquire(int acquires) {
-            final Thread current = Thread.currentThread();
-            int c = getState();
-            // 这里如果state还是0说明锁还空着
-            if (c == 0) {
-                // 因为是公平锁版本的，先去看下是否阻塞队列里有排着队的
-                if (!hasQueuedPredecessors() &&
-                    compareAndSetState(0, acquires)) {
-                    // 没有排队的，并且state使用cas设置成功的就标记当前占有锁的线程是我
-                    setExclusiveOwnerThread(current);
-                    // 然后其实就返回了，包括阻塞队列的head和tail节点和waitStatus都没有设置
-                    return true;
-                }
-            }
-            else if (current == getExclusiveOwnerThread()) {
-                int nextc = c + acquires;
-                if (nextc < 0)
-                    throw new Error("Maximum lock count exceeded");
-                setState(nextc);
-                return true;
-            }
-            // 这里就是第二个线程会返回false
-            return false;
-        }
-    }

+    2021 年中总结
+    /2021/07/18/2021-%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
+    又到半年总结时，第一次写总结类型的文章感觉挺好写的，但是后面总觉得这过去的一段时间所做的事情，能力上的成长低于预期，但是是需要总结下，找找问题，顺便展望下未来。

+
这一年做的最让自己满意的应该就是看了一些书，由折腾群洋总发起的读书打卡活动，到目前为止已经读完了这几本书，《cUrl 必知必会》，《古董局中局 1》，《古董局中局 2》，《算法图解》，《每天 5 分钟玩转 Kubernetes》《幸福了吗？》《高可用可伸缩微服务架构：基于 Dubbo、Spring Cloud和 Service Mesh》《Rust 权威指南》后面可以写个专题说说看的这些书，虽然每天打卡如果时间安排不好，并且看的书像 rust 这样比较难的话还是会有点小焦虑，不过也是个调整过程，一方面可以在白天就抽空看一会，然后也不必要每次都看很大一章，注重吸收。

+
技术上的成长的话，有一些比较小的长进吧，对于一些之前忽视的 synchronized，ThreadLocal 和 AQS 等知识点做了下查漏补缺了，然后多了解了一些 Java 垃圾回收的内容，但是在实操上还是比较欠缺，成型的技术方案，架构上所谓的优化也比较少，一些想法也还有考虑不周全的地方，还需要多花时间和心思去学习加强，特别是在目前已经有的基础上如何做系统深层次的优化，既不要是鸡毛蒜皮的，也不能出现一些不可接受的问题和故障，这是个很重要的课题，需要好好学习，后面考虑定一些周期性目标，两个月左右能有一些成果和总结。

+
另外一部分是自己的服务，因为 ucloud 的机器太贵就没续费了，所以都迁移到腾讯云的小机器上了，顺便折腾了一点点 traefik，但是还很不熟练，不太习惯这一套，一方面是 docker 还不习惯，这也加重了对这套环境的不适应，还是习惯裸机部署，另一方面就是 k8s 了，家里的机器还没虚拟化，没有很好的条件可以做实验，这也是读书打卡的一个没做好的点，整体的学习效果受限于深度和实操，后面是看都是用 traefik，也找到了一篇文章可以 traefik 转发到裸机应用，因为主仓库用的是裸机的 gogs。

+
还有就是运动减肥上，唉，这又是很大的一个痛点，基本没效果，只是还算稳定，昨天看到一个视频说还需要力量训练来增肌，以此可以提升基础代谢，打算往这个方向尝试下，因为今天没有疫情限制了，在 6 月底完成了 200 公里的跑步小目标，只是有些膝盖跟大腿根外侧不适，抽空得去看下医生，后面打算每天也能做点卷腹跟俯卧撑。

+
下半年还希望能继续多看看书，比很多网上各种乱七八糟的文章会好很多，结合豆瓣评分，找一些评价高一些的文章，但也不是说分稍低点的就不行，有些也看人是不是适合，一般 6 分以上评价比较多的就可以试试。

+]]>
+      
+        生活
+        年中总结
+        2021
+      
+      
+        生活
+        2021
+        年中总结
+        技术
+        读书
+      
+  
+  
+    AbstractQueuedSynchronizer
+    /2019/09/23/AbstractQueuedSynchronizer/
+    最近看了大神的 AQS 的文章，之前总是断断续续地看一点，每次都知难而退，下次看又从头开始，昨天总算硬着头皮看完了第一部分
首先 AQS 只要有这些属性

+
// 头结点，你直接把它当做 当前持有锁的线程 可能是最好理解的
+private transient volatile Node head;
 
-
第二个线程
当第二个线程进来的时候应该是怎么样，结合代码来看

-
/**
-     * Acquires in exclusive mode, ignoring interrupts.  Implemented
-     * by invoking at least once {@link #tryAcquire},
-     * returning on success.  Otherwise the thread is queued, possibly
-     * repeatedly blocking and unblocking, invoking {@link
-     * #tryAcquire} until success.  This method can be used
-     * to implement method {@link Lock#lock}.
-     *
-     * @param arg the acquire argument.  This value is conveyed to
-     *        {@link #tryAcquire} but is otherwise uninterpreted and
-     *        can represent anything you like.
-     */
-    public final void acquire(int arg) {
-        // 前面第一种情况是tryAcquire直接成功了，这个if判断第一个条件就是false，就不往下执行了
-        // 如果是第二个线程，第一个条件获取锁不成功，条件判断!tryAcquire(arg) == true，就会走
-        // acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
-        if (!tryAcquire(arg) &&
-            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
-            selfInterrupt();
-    }

+// 阻塞的尾节点，每个新的节点进来，都插入到最后，也就形成了一个链表
+private transient volatile Node tail;
 
-
然后来看下addWaiter的逻辑

-
/**
-     * Creates and enqueues node for current thread and given mode.
-     *
-     * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
-     * @return the new node
-     */
-    private Node addWaiter(Node mode) {
-        // 这里是包装成一个node
-        Node node = new Node(Thread.currentThread(), mode);
-        // Try the fast path of enq; backup to full enq on failure
-        // 最快的方式就是把当前线程的节点放在阻塞队列的最后
-        Node pred = tail;
-        // 只有当tail，也就是pred不为空的时候可以直接接上
-        if (pred != null) {
-            node.prev = pred;
-            // 如果这里cas成功了，就直接接上返回了
-            if (compareAndSetTail(pred, node)) {
-                pred.next = node;
-                return node;
-            }
-        }
-        // 不然就会继续走到这里
-        enq(node);
-        return node;
-    }

+// 这个是最重要的，代表当前锁的状态，0代表没有被占用，大于 0 代表有线程持有当前锁
+// 这个值可以大于 1，是因为锁可以重入，每次重入都加上 1
+private volatile int state;
 
-
然后就是enq的逻辑了

-
/**
-     * Inserts node into queue, initializing if necessary. See picture above.
-     * @param node the node to insert
-     * @return node's predecessor
-     */
-    private Node enq(final Node node) {
-        for (;;) {
-            // 如果状态没变化的话，tail这时还是null的
-            Node t = tail;
-            if (t == null) { // Must initialize
-                // 这里就会初始化头结点，就是个空节点
-                if (compareAndSetHead(new Node()))
-                    // tail也赋值成head
-                    tail = head;
-            } else {
-                // 这里就设置tail了
-                node.prev = t;
-                if (compareAndSetTail(t, node)) {
-                    t.next = node;
-                    return t;
-                }
-            }
-        }
-    }

+// 代表当前持有独占锁的线程，举个最重要的使用例子，因为锁可以重入
+// reentrantLock.lock()可以嵌套调用多次，所以每次用这个来判断当前线程是否已经拥有了锁
+// if (currentThread == getExclusiveOwnerThread()) {state++}
+private transient Thread exclusiveOwnerThread; //继承自AbstractOwnableSynchronizer

+
大概了解了 aqs 底层的双向等待队列，
结构是这样的

每个 node 里面主要是的代码结构也比较简单

+
static final class Node {
+    // 标识节点当前在共享模式下
+    static final Node SHARED = new Node();
+    // 标识节点当前在独占模式下
+    static final Node EXCLUSIVE = null;
 
-
所以从这里可以看出来，其实head头结点不是个真实的带有线程的节点，并且不是在第一个线程进来的时候设置的

-
解锁
通过代码来看下

-
/**
-     * Attempts to release this lock.
-     *
-     * <p>If the current thread is the holder of this lock then the hold
-     * count is decremented.  If the hold count is now zero then the lock
-     * is released.  If the current thread is not the holder of this
-     * lock then {@link IllegalMonitorStateException} is thrown.
-     *
-     * @throws IllegalMonitorStateException if the current thread does not
-     *         hold this lock
-     */
-    public void unlock() {
-        // 释放锁
-        sync.release(1);
-    }
-/**
-     * Releases in exclusive mode.  Implemented by unblocking one or
-     * more threads if {@link #tryRelease} returns true.
-     * This method can be used to implement method {@link Lock#unlock}.
-     *
-     * @param arg the release argument.  This value is conveyed to
-     *        {@link #tryRelease} but is otherwise uninterpreted and
-     *        can represent anything you like.
-     * @return the value returned from {@link #tryRelease}
-     */
-    public final boolean release(int arg) {
-        // 尝试去释放
-        if (tryRelease(arg)) {
-            Node h = head;
-            if (h != null && h.waitStatus != 0)
-                unparkSuccessor(h);
-            return true;
-        }
-        return false;
-    }
-protected final boolean tryRelease(int releases) {
-            int c = getState() - releases;
-            if (Thread.currentThread() != getExclusiveOwnerThread())
-                throw new IllegalMonitorStateException();
-            boolean free = false;
-    		// 判断是否完全释放锁，因为可重入
-            if (c == 0) {
-                free = true;
-                setExclusiveOwnerThread(null);
-            }
-            setState(c);
-            return free;
-        }
-// 这段代码和上面的一致，只是为了顺序性，又拷下来看下
-
-public final boolean release(int arg) {
-        // 尝试去释放，如果是完全释放，返回的就是true，否则是false
-        if (tryRelease(arg)) {
-            Node h = head;
-            // 这里判断头结点是否为空以及waitStatus的状态，前面说了head节点其实是
-            // 在第二个线程进来的时候初始化的，如果是空的话说明没后续节点，并且waitStatus
-            // 也表示了后续的等待状态
-            if (h != null && h.waitStatus != 0)
-                unparkSuccessor(h);
-            return true;
-        }
-        return false;
-    }
-
-/**
-     * Wakes up node's successor, if one exists.
-     *
-     * @param node the node
-     */
-// 唤醒后继节点
-    private void unparkSuccessor(Node node) {
-        /*
-         * If status is negative (i.e., possibly needing signal) try
-         * to clear in anticipation of signalling.  It is OK if this
-         * fails or if status is changed by waiting thread.
-         */
-        int ws = node.waitStatus;
-        if (ws < 0)
-            compareAndSetWaitStatus(node, ws, 0);
-
-        /*
-         * Thread to unpark is held in successor, which is normally
-         * just the next node.  But if cancelled or apparently null,
-         * traverse backwards from tail to find the actual
-         * non-cancelled successor.
-         */
-        Node s = node.next;
-        // 如果后继节点是空或者当前节点取消等待了
-        if (s == null || s.waitStatus > 0) {
-            s = null;
-            // 从后往前找，找到非取消的节点，注意这里不是找到就退出，而是一直找到头
-            // 所以不必担心中间有取消的
-            for (Node t = tail; t != null && t != node; t = t.prev)
-                if (t.waitStatus <= 0)
-                    s = t;
-        }
-        if (s != null)
-            // 将其唤醒
-            LockSupport.unpark(s.thread);
-    }

-
-
-
-
-]]>
-      
-        Java
-        并发
-      
-      
-        java
-        并发
-        j.u.c
-        aqs
-      
-  
-  
-    AbstractQueuedSynchronizer
-    /2019/09/23/AbstractQueuedSynchronizer/
-    最近看了大神的 AQS 的文章，之前总是断断续续地看一点，每次都知难而退，下次看又从头开始，昨天总算硬着头皮看完了第一部分
首先 AQS 只要有这些属性

-
// 头结点，你直接把它当做 当前持有锁的线程 可能是最好理解的
-private transient volatile Node head;
-
-// 阻塞的尾节点，每个新的节点进来，都插入到最后，也就形成了一个链表
-private transient volatile Node tail;
-
-// 这个是最重要的，代表当前锁的状态，0代表没有被占用，大于 0 代表有线程持有当前锁
-// 这个值可以大于 1，是因为锁可以重入，每次重入都加上 1
-private volatile int state;
-
-// 代表当前持有独占锁的线程，举个最重要的使用例子，因为锁可以重入
-// reentrantLock.lock()可以嵌套调用多次，所以每次用这个来判断当前线程是否已经拥有了锁
-// if (currentThread == getExclusiveOwnerThread()) {state++}
-private transient Thread exclusiveOwnerThread; //继承自AbstractOwnableSynchronizer

-
大概了解了 aqs 底层的双向等待队列，
结构是这样的

每个 node 里面主要是的代码结构也比较简单

-
static final class Node {
-    // 标识节点当前在共享模式下
-    static final Node SHARED = new Node();
-    // 标识节点当前在独占模式下
-    static final Node EXCLUSIVE = null;
-
-    // ======== 下面的几个int常量是给waitStatus用的 ===========
-    /** waitStatus value to indicate thread has cancelled */
-    // 代码此线程取消了争抢这个锁
-    static final int CANCELLED =  1;
-    /** waitStatus value to indicate successor's thread needs unparking */
-    // 官方的描述是，其表示当前node的后继节点对应的线程需要被唤醒
-    static final int SIGNAL    = -1;
-    /** waitStatus value to indicate thread is waiting on condition */
-    // 本文不分析condition，所以略过吧，下一篇文章会介绍这个
-    static final int CONDITION = -2;
-    /**
-     * waitStatus value to indicate the next acquireShared should
-     * unconditionally propagate
+    // ======== 下面的几个int常量是给waitStatus用的 ===========
+    /** waitStatus value to indicate thread has cancelled */
+    // 代码此线程取消了争抢这个锁
+    static final int CANCELLED =  1;
+    /** waitStatus value to indicate successor's thread needs unparking */
+    // 官方的描述是，其表示当前node的后继节点对应的线程需要被唤醒
+    static final int SIGNAL    = -1;
+    /** waitStatus value to indicate thread is waiting on condition */
+    // 本文不分析condition，所以略过吧，下一篇文章会介绍这个
+    static final int CONDITION = -2;
+    /**
+     * waitStatus value to indicate the next acquireShared should
+     * unconditionally propagate
      */
     // 同样的不分析，略过吧
     static final int PROPAGATE = -3;
@@ -1315,131 +1070,248 @@ Node *clone(Node *graph) {
       
   
   
-    Disruptor 系列一
-    /2022/02/13/Disruptor-%E7%B3%BB%E5%88%97%E4%B8%80/
-    很久之前就听说过这个框架，不过之前有点跟消息队列混起来，这个也是种队列，但不是跟 rocketmq，nsq 那种一样的，而是在进程内部提供队列服务的，偏向于取代ArrayBlockingQueue，因为这个阻塞队列是使用了锁来控制阻塞，关于并发其实有一些通用的最佳实践，就是用锁，即使是 JDK 提供的锁，也是比较耗资源的，当然这是跟不加锁的对比，同样是锁，JDK 的实现还是性能比较优秀的。常见的阻塞队列中例如 ArrayBlockingQueue 和 LinkedBlockingQueue 都有锁的身影的存在，区别在于 ArrayBlockingQueue 是一把锁，后者是两把锁，不过重点不在几把锁，这里其实是两个问题，一个是所谓的 lock free, 对于一个单生产者的 disruptor 来说，因为写入是只有一个线程的，是可以不用加锁，多生产者的时候使用的是 cas 来获取对应的写入坑位，另一个是解决“伪共享”问题，后面可以详细点分析，先介绍下使用
首先是数据源

-
public class LongEvent {
-    private long value;
-
-    public void set(long value) {
-        this.value = value;
-    }
+    AQS篇一
+    /2021/02/14/AQS%E7%AF%87%E4%B8%80/
+    很多东西都是时看时新，而且时间长了也会忘，所以再来复习下，也会有一些新的角度看法这次来聊下AQS的内容，主要是这几个点，

+
第一个线程
第一个线程抢到锁了，此时state跟阻塞队列是怎么样的，其实这里是之前没理解对的地方

+
/**
+         * Fair version of tryAcquire.  Don't grant access unless
+         * recursive call or no waiters or is first.
+         */
+        protected final boolean tryAcquire(int acquires) {
+            final Thread current = Thread.currentThread();
+            int c = getState();
+            // 这里如果state还是0说明锁还空着
+            if (c == 0) {
+                // 因为是公平锁版本的，先去看下是否阻塞队列里有排着队的
+                if (!hasQueuedPredecessors() &&
+                    compareAndSetState(0, acquires)) {
+                    // 没有排队的，并且state使用cas设置成功的就标记当前占有锁的线程是我
+                    setExclusiveOwnerThread(current);
+                    // 然后其实就返回了，包括阻塞队列的head和tail节点和waitStatus都没有设置
+                    return true;
+                }
+            }
+            else if (current == getExclusiveOwnerThread()) {
+                int nextc = c + acquires;
+                if (nextc < 0)
+                    throw new Error("Maximum lock count exceeded");
+                setState(nextc);
+                return true;
+            }
+            // 这里就是第二个线程会返回false
+            return false;
+        }
+    }

 
-    public long getValue() {
-        return value;
-    }
+
第二个线程
当第二个线程进来的时候应该是怎么样，结合代码来看

+
/**
+     * Acquires in exclusive mode, ignoring interrupts.  Implemented
+     * by invoking at least once {@link #tryAcquire},
+     * returning on success.  Otherwise the thread is queued, possibly
+     * repeatedly blocking and unblocking, invoking {@link
+     * #tryAcquire} until success.  This method can be used
+     * to implement method {@link Lock#lock}.
+     *
+     * @param arg the acquire argument.  This value is conveyed to
+     *        {@link #tryAcquire} but is otherwise uninterpreted and
+     *        can represent anything you like.
+     */
+    public final void acquire(int arg) {
+        // 前面第一种情况是tryAcquire直接成功了，这个if判断第一个条件就是false，就不往下执行了
+        // 如果是第二个线程，第一个条件获取锁不成功，条件判断!tryAcquire(arg) == true，就会走
+        // acquireQueued(addWaiter(Node.EXCLUSIVE), arg)
+        if (!tryAcquire(arg) &&
+            acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
+            selfInterrupt();
+    }

 
-    public void setValue(long value) {
-        this.value = value;
-    }
-}

-
事件生产

-
public class LongEventFactory implements EventFactory<LongEvent>
-{
-    public LongEvent newInstance()
-    {
-        return new LongEvent();
-    }
-}

-
事件处理器

-
public class LongEventHandler implements EventHandler<LongEvent> {
+
然后来看下addWaiter的逻辑

+
/**
+     * Creates and enqueues node for current thread and given mode.
+     *
+     * @param mode Node.EXCLUSIVE for exclusive, Node.SHARED for shared
+     * @return the new node
+     */
+    private Node addWaiter(Node mode) {
+        // 这里是包装成一个node
+        Node node = new Node(Thread.currentThread(), mode);
+        // Try the fast path of enq; backup to full enq on failure
+        // 最快的方式就是把当前线程的节点放在阻塞队列的最后
+        Node pred = tail;
+        // 只有当tail，也就是pred不为空的时候可以直接接上
+        if (pred != null) {
+            node.prev = pred;
+            // 如果这里cas成功了，就直接接上返回了
+            if (compareAndSetTail(pred, node)) {
+                pred.next = node;
+                return node;
+            }
+        }
+        // 不然就会继续走到这里
+        enq(node);
+        return node;
+    }

 
-    // event 事件，
-    // sequence 当前的序列 
-    // 是否当前批次最后一个数据
-    public void onEvent(LongEvent event, long sequence, boolean endOfBatch)
-    {
-        String str = String.format("long event : %s l:%s b:%s", event.getValue(), sequence, endOfBatch);
-        System.out.println(str);
-    }
-}
-

-
主方法代码

-
package disruptor;
+
然后就是enq的逻辑了

+
/**
+     * Inserts node into queue, initializing if necessary. See picture above.
+     * @param node the node to insert
+     * @return node's predecessor
+     */
+    private Node enq(final Node node) {
+        for (;;) {
+            // 如果状态没变化的话，tail这时还是null的
+            Node t = tail;
+            if (t == null) { // Must initialize
+                // 这里就会初始化头结点，就是个空节点
+                if (compareAndSetHead(new Node()))
+                    // tail也赋值成head
+                    tail = head;
+            } else {
+                // 这里就设置tail了
+                node.prev = t;
+                if (compareAndSetTail(t, node)) {
+                    t.next = node;
+                    return t;
+                }
+            }
+        }
+    }

 
-import com.lmax.disruptor.RingBuffer;
-import com.lmax.disruptor.dsl.Disruptor;
-import com.lmax.disruptor.util.DaemonThreadFactory;
+
所以从这里可以看出来，其实head头结点不是个真实的带有线程的节点，并且不是在第一个线程进来的时候设置的

+
解锁
通过代码来看下

+
/**
+     * Attempts to release this lock.
+     *
+     * <p>If the current thread is the holder of this lock then the hold
+     * count is decremented.  If the hold count is now zero then the lock
+     * is released.  If the current thread is not the holder of this
+     * lock then {@link IllegalMonitorStateException} is thrown.
+     *
+     * @throws IllegalMonitorStateException if the current thread does not
+     *         hold this lock
+     */
+    public void unlock() {
+        // 释放锁
+        sync.release(1);
+    }
+/**
+     * Releases in exclusive mode.  Implemented by unblocking one or
+     * more threads if {@link #tryRelease} returns true.
+     * This method can be used to implement method {@link Lock#unlock}.
+     *
+     * @param arg the release argument.  This value is conveyed to
+     *        {@link #tryRelease} but is otherwise uninterpreted and
+     *        can represent anything you like.
+     * @return the value returned from {@link #tryRelease}
+     */
+    public final boolean release(int arg) {
+        // 尝试去释放
+        if (tryRelease(arg)) {
+            Node h = head;
+            if (h != null && h.waitStatus != 0)
+                unparkSuccessor(h);
+            return true;
+        }
+        return false;
+    }
+protected final boolean tryRelease(int releases) {
+            int c = getState() - releases;
+            if (Thread.currentThread() != getExclusiveOwnerThread())
+                throw new IllegalMonitorStateException();
+            boolean free = false;
+    		// 判断是否完全释放锁，因为可重入
+            if (c == 0) {
+                free = true;
+                setExclusiveOwnerThread(null);
+            }
+            setState(c);
+            return free;
+        }
+// 这段代码和上面的一致，只是为了顺序性，又拷下来看下
 
-import java.nio.ByteBuffer;
+public final boolean release(int arg) {
+        // 尝试去释放，如果是完全释放，返回的就是true，否则是false
+        if (tryRelease(arg)) {
+            Node h = head;
+            // 这里判断头结点是否为空以及waitStatus的状态，前面说了head节点其实是
+            // 在第二个线程进来的时候初始化的，如果是空的话说明没后续节点，并且waitStatus
+            // 也表示了后续的等待状态
+            if (h != null && h.waitStatus != 0)
+                unparkSuccessor(h);
+            return true;
+        }
+        return false;
+    }
 
-public class LongEventMain
-{
-    public static void main(String[] args) throws Exception
-    {
-        // 这个需要是 2 的幂次，这样在定位的时候只需要位移操作，也能减少各种计算操作
-        int bufferSize = 1024; 
+/**
+     * Wakes up node's successor, if one exists.
+     *
+     * @param node the node
+     */
+// 唤醒后继节点
+    private void unparkSuccessor(Node node) {
+        /*
+         * If status is negative (i.e., possibly needing signal) try
+         * to clear in anticipation of signalling.  It is OK if this
+         * fails or if status is changed by waiting thread.
+         */
+        int ws = node.waitStatus;
+        if (ws < 0)
+            compareAndSetWaitStatus(node, ws, 0);
+
+        /*
+         * Thread to unpark is held in successor, which is normally
+         * just the next node.  But if cancelled or apparently null,
+         * traverse backwards from tail to find the actual
+         * non-cancelled successor.
+         */
+        Node s = node.next;
+        // 如果后继节点是空或者当前节点取消等待了
+        if (s == null || s.waitStatus > 0) {
+            s = null;
+            // 从后往前找，找到非取消的节点，注意这里不是找到就退出，而是一直找到头
+            // 所以不必担心中间有取消的
+            for (Node t = tail; t != null && t != node; t = t.prev)
+                if (t.waitStatus <= 0)
+                    s = t;
+        }
+        if (s != null)
+            // 将其唤醒
+            LockSupport.unpark(s.thread);
+    }

 
-        Disruptor<LongEvent> disruptor = 
-                new Disruptor<>(LongEvent::new, bufferSize, DaemonThreadFactory.INSTANCE);
 
-        // 类似于注册处理器
-        disruptor.handleEventsWith(new LongEventHandler());
-        // 或者直接用 lambda
-        disruptor.handleEventsWith((event, sequence, endOfBatch) ->
-                System.out.println("Event: " + event));
-        // 启动我们的 disruptor
-        disruptor.start(); 
 
 
-        RingBuffer<LongEvent> ringBuffer = disruptor.getRingBuffer(); 
-        ByteBuffer bb = ByteBuffer.allocate(8);
-        for (long l = 0; true; l++)
-        {
-            bb.putLong(0, l);
-            // 生产事件
-            ringBuffer.publishEvent((event, sequence, buffer) -> event.set(buffer.getLong(0)), bb);
-            Thread.sleep(1000);
-        }
-    }
-}

-
运行下可以看到运行结果

这里其实就只是最简单的使用，生产者只有一个，然后也不是批量的。

 ]]>
       
         Java
+        并发
       
       
-        Java
-        Disruptor
+        java
+        并发
+        j.u.c
+        aqs
       
   
   
-    Disruptor 系列二
-    /2022/02/27/Disruptor-%E7%B3%BB%E5%88%97%E4%BA%8C/
-    这里开始慢慢深入的讲一下 disruptor，首先是 lock free , 相比于前面介绍的两个阻塞队列，
disruptor 本身是不直接使用锁的，因为本身的设计是单个线程去生产，通过 cas 来维护头指针，
不直接维护尾指针，这样就减少了锁的使用，提升了性能；第二个是这次介绍的重点，
减少 false sharing 的情况，也就是常说的 伪共享 问题，那么什么叫 伪共享 呢，
这里要扯到一些 cpu 缓存的知识，

譬如我在用的这个笔记本

这里就可能看到 L2 Cache 就是针对每个核的

这里可以看到现代 CPU 的结构里，分为三级缓存，越靠近 cpu 的速度越快，存储容量越小，
而 L1 跟 L2 是 CPU 核专属的每个核都有自己的 L1 和 L2 的，其中 L1 还分为数据和指令，
像我上面的图中显示的 L1 Cache 只有 64KB 大小，其中数据 32KB，指令 32KB，
而 L2 则有 256KB，L3 有 4MB，其中的 Line Size 是我们这里比较重要的一个值，
CPU 其实会就近地从 Cache 中读取数据，碰到 Cache Miss 就再往下一级 Cache 读取，
每次读取是按照缓存行 Cache Line 读取，并且也遵循了“就近原则”，
也就是相近的数据有可能也会马上被读取，所以以行的形式读取，然而这也造成了 false sharing，
因为类似于 ArrayBlockingQueue，需要有 takeIndex , putIndex , count , 因为在同一个类中，
很有可能存在于同一个 Cache Line 中，但是这几个值会被不同的线程修改，
导致从 Cache 取出来以后立马就会被失效，所谓的就近原则也就没用了，
因为需要反复地标记 dirty 脏位，然后把 Cache 刷掉，就造成了false sharing这种情况
而在 disruptor 中则使用了填充的方式，让我的头指针能够不产生false sharing

-
class LhsPadding
-{
-    protected long p1, p2, p3, p4, p5, p6, p7;
-}
-
-class Value extends LhsPadding
-{
-    protected volatile long value;
-}
-
-class RhsPadding extends Value
-{
-    protected long p9, p10, p11, p12, p13, p14, p15;
-}
-
-/**
- * <p>Concurrent sequence class used for tracking the progress of
- * the ring buffer and event processors.  Support a number
- * of concurrent operations including CAS and order writes.
- *
- * <p>Also attempts to be more efficient with regards to false
- * sharing by adding padding around the volatile field.
- */
-public class Sequence extends RhsPadding
-{

-
通过代码可以看到，sequence 中其实真正有意义的是 value 字段，因为需要在多线程环境下可见也
使用了volatile 关键字，而 LhsPadding 和 RhsPadding 分别在value 前后填充了各
7 个 long 型的变量，long 型的变量在 Java 中是占用 8 bytes，这样就相当于不管怎么样，
value 都会单独使用一个缓存行，使得其不会产生 false sharing 的问题。

+    2021 年终总结
+    /2022/01/22/2021-%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
+    又是一年年终总结，本着极度讨厌实时需求的理念，我还是 T+N 发布这个年终总结

+
工作篇
工作没什么大变化，有了些微的提升，可能因为是来了之后做了些项目对比公司与来还算是比较重要的，但是技术难度上没有特别突出的点，可能最开始用 openresty+lua 做了个 ab 测的工具，还是让我比较满意的，后面一般都是业务型的需求，今年可能在业务相关的技术逻辑上有了一些深度的了解，而原来一直想做的业务架构升级和通用型技术中间件这样的优化还是停留在想象中，前面说的 ab 测应该算是个半成品，还是没能多走出这一步，得需要多做一些实在的事情，比如轻量级的业务框架，能够对原先不熟悉的业务逻辑，代码逻辑有比较深入的理解，而不是一直都是让特定的同学负责特定的逻辑，很多时候还是在偷懒，习惯以一些简单安全的方案去做事情，在技术上还是要有所追求，还有就是能够在新语言，主要是 rust，swift 这类的能有些小玩具可以做，rust 的话是因为今年看了一本相关的书，后面三分之一其实消化得不好，这本书整体来说是很不错的，只是 rust 本身在所有权这块，还有引用包装等方面是设计得比较难懂，也可能是我基础差，所以还是想在复习下，可以做一个简单的命令行工具这种，然后 swift 是想说可以做点 mac 的小软件，原生的毕竟性能好点，又小。基于 web 做的客户端大部分都是又丑又大，极少数能好看点，但也是很重，起码 7~80M 的大小，原生的估计能除以 10。
整体的职业规划貌似陷入了比较大的困惑期，在目前公司发展前景不是很大，但是出去貌似也没有比较适合我的机会，总的来说还是杭州比较卷，个人觉得有自己的时间是非常重要的，而且这个不光是用来自我提升的，还是让自己有足够的时间做缓冲，有足够的时间锻炼减肥，时间少的情况下，不光会在仅有的时间里暴饮暴食，还没空锻炼，身体是革命的本钱，现在其实能特别明显地感觉到身体状态下滑，容易疲劳，焦虑。所以是否也许有可能以后要往外企这类的方向去发展。
工作上其实还是有个不大不小的缺点，就是容易激动，容易焦虑，前一点可能有稍稍地改观，因为工作中的很多现状其实是我个人难以改变的，即使觉得不合理，但是结构在那里，还不如自己放宽心，尽量做好事情就行。第二点的话还是做得比较差，一直以来抗压能力都比较差，跟成长环境，家庭环境都有比较大的关系，而且说实在的特别是父母，基本也没有在这方面给我正向的帮助，比较擅长给我施压，从小就是通过压力让我好好读书，当个乖学生，考个好学校，并没有能真正地理解我的压力，教我或者帮助我解压，只会在那说着不着边际的空话，甚至经常反过来对我施压。还是希望能慢慢解开，这点可能对我身体也有影响，也许需要看一些心理疏导相关的书籍。工作篇暂时到这，后续还有其他篇，未完待续哈哈😀

 ]]>
       
-        Java
+        生活
+        年终总结
       
       
-        Java
-        Disruptor
+        生活
+        年终总结
+        2021
+        拖更
       
   
   
@@ -2692,6 +2564,45 @@ Node *clone(Node *graph) {
         题解
       
   
+  
+    Disruptor 系列二
+    /2022/02/27/Disruptor-%E7%B3%BB%E5%88%97%E4%BA%8C/
+    这里开始慢慢深入的讲一下 disruptor，首先是 lock free , 相比于前面介绍的两个阻塞队列，
disruptor 本身是不直接使用锁的，因为本身的设计是单个线程去生产，通过 cas 来维护头指针，
不直接维护尾指针，这样就减少了锁的使用，提升了性能；第二个是这次介绍的重点，
减少 false sharing 的情况，也就是常说的 伪共享 问题，那么什么叫 伪共享 呢，
这里要扯到一些 cpu 缓存的知识，

譬如我在用的这个笔记本

这里就可能看到 L2 Cache 就是针对每个核的

这里可以看到现代 CPU 的结构里，分为三级缓存，越靠近 cpu 的速度越快，存储容量越小，
而 L1 跟 L2 是 CPU 核专属的每个核都有自己的 L1 和 L2 的，其中 L1 还分为数据和指令，
像我上面的图中显示的 L1 Cache 只有 64KB 大小，其中数据 32KB，指令 32KB，
而 L2 则有 256KB，L3 有 4MB，其中的 Line Size 是我们这里比较重要的一个值，
CPU 其实会就近地从 Cache 中读取数据，碰到 Cache Miss 就再往下一级 Cache 读取，
每次读取是按照缓存行 Cache Line 读取，并且也遵循了“就近原则”，
也就是相近的数据有可能也会马上被读取，所以以行的形式读取，然而这也造成了 false sharing，
因为类似于 ArrayBlockingQueue，需要有 takeIndex , putIndex , count , 因为在同一个类中，
很有可能存在于同一个 Cache Line 中，但是这几个值会被不同的线程修改，
导致从 Cache 取出来以后立马就会被失效，所谓的就近原则也就没用了，
因为需要反复地标记 dirty 脏位，然后把 Cache 刷掉，就造成了false sharing这种情况
而在 disruptor 中则使用了填充的方式，让我的头指针能够不产生false sharing

+
class LhsPadding
+{
+    protected long p1, p2, p3, p4, p5, p6, p7;
+}
+
+class Value extends LhsPadding
+{
+    protected volatile long value;
+}
+
+class RhsPadding extends Value
+{
+    protected long p9, p10, p11, p12, p13, p14, p15;
+}
+
+/**
+ * <p>Concurrent sequence class used for tracking the progress of
+ * the ring buffer and event processors.  Support a number
+ * of concurrent operations including CAS and order writes.
+ *
+ * <p>Also attempts to be more efficient with regards to false
+ * sharing by adding padding around the volatile field.
+ */
+public class Sequence extends RhsPadding
+{

+
通过代码可以看到，sequence 中其实真正有意义的是 value 字段，因为需要在多线程环境下可见也
使用了volatile 关键字，而 LhsPadding 和 RhsPadding 分别在value 前后填充了各
7 个 long 型的变量，long 型的变量在 Java 中是占用 8 bytes，这样就相当于不管怎么样，
value 都会单独使用一个缓存行，使得其不会产生 false sharing 的问题。

+]]>
+      
+        Java
+      
+      
+        Java
+        Disruptor
+      
+  
   
     Leetcode 028 实现 strStr() ( Implement strStr() ) 题解分析
     /2021/10/31/Leetcode-028-%E5%AE%9E%E7%8E%B0-strStr-Implement-strStr-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -3027,15 +2938,104 @@ inorder = [9,3,15,20,7]
   
-    Leetcode 155 最小栈(Min Stack) 题解分析
-    /2020/12/06/Leetcode-155-%E6%9C%80%E5%B0%8F%E6%A0%88-Min-Stack-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
-    题目介绍
Design a stack that supports push, pop, top, and retrieving the minimum element in constant time.
设计一个栈，支持压栈，出站，获取栈顶元素，通过常数级复杂度获取栈中的最小元素

-
    
-
  • push(x) – Push element x onto stack.
    • 
-
  • pop() – Removes the element on top of the stack.
    • 
-
  • top() – Get the top element.
    • 
-
  • getMin() – Retrieve the minimum element in the stack.
    • 
-

+    Disruptor 系列一
+    /2022/02/13/Disruptor-%E7%B3%BB%E5%88%97%E4%B8%80/
+    很久之前就听说过这个框架，不过之前有点跟消息队列混起来，这个也是种队列，但不是跟 rocketmq，nsq 那种一样的，而是在进程内部提供队列服务的，偏向于取代ArrayBlockingQueue，因为这个阻塞队列是使用了锁来控制阻塞，关于并发其实有一些通用的最佳实践，就是用锁，即使是 JDK 提供的锁，也是比较耗资源的，当然这是跟不加锁的对比，同样是锁，JDK 的实现还是性能比较优秀的。常见的阻塞队列中例如 ArrayBlockingQueue 和 LinkedBlockingQueue 都有锁的身影的存在，区别在于 ArrayBlockingQueue 是一把锁，后者是两把锁，不过重点不在几把锁，这里其实是两个问题，一个是所谓的 lock free, 对于一个单生产者的 disruptor 来说，因为写入是只有一个线程的，是可以不用加锁，多生产者的时候使用的是 cas 来获取对应的写入坑位，另一个是解决“伪共享”问题，后面可以详细点分析，先介绍下使用
首先是数据源

+
public class LongEvent {
+    private long value;
+
+    public void set(long value) {
+        this.value = value;
+    }
+
+    public long getValue() {
+        return value;
+    }
+
+    public void setValue(long value) {
+        this.value = value;
+    }
+}

+
事件生产

+
public class LongEventFactory implements EventFactory<LongEvent>
+{
+    public LongEvent newInstance()
+    {
+        return new LongEvent();
+    }
+}

+
事件处理器

+
public class LongEventHandler implements EventHandler<LongEvent> {
+
+    // event 事件，
+    // sequence 当前的序列 
+    // 是否当前批次最后一个数据
+    public void onEvent(LongEvent event, long sequence, boolean endOfBatch)
+    {
+        String str = String.format("long event : %s l:%s b:%s", event.getValue(), sequence, endOfBatch);
+        System.out.println(str);
+    }
+}
+

+
主方法代码

+
package disruptor;
+
+import com.lmax.disruptor.RingBuffer;
+import com.lmax.disruptor.dsl.Disruptor;
+import com.lmax.disruptor.util.DaemonThreadFactory;
+
+import java.nio.ByteBuffer;
+
+public class LongEventMain
+{
+    public static void main(String[] args) throws Exception
+    {
+        // 这个需要是 2 的幂次，这样在定位的时候只需要位移操作，也能减少各种计算操作
+        int bufferSize = 1024; 
+
+        Disruptor<LongEvent> disruptor = 
+                new Disruptor<>(LongEvent::new, bufferSize, DaemonThreadFactory.INSTANCE);
+
+        // 类似于注册处理器
+        disruptor.handleEventsWith(new LongEventHandler());
+        // 或者直接用 lambda
+        disruptor.handleEventsWith((event, sequence, endOfBatch) ->
+                System.out.println("Event: " + event));
+        // 启动我们的 disruptor
+        disruptor.start(); 
+
+
+        RingBuffer<LongEvent> ringBuffer = disruptor.getRingBuffer(); 
+        ByteBuffer bb = ByteBuffer.allocate(8);
+        for (long l = 0; true; l++)
+        {
+            bb.putLong(0, l);
+            // 生产事件
+            ringBuffer.publishEvent((event, sequence, buffer) -> event.set(buffer.getLong(0)), bb);
+            Thread.sleep(1000);
+        }
+    }
+}

+
运行下可以看到运行结果

这里其实就只是最简单的使用，生产者只有一个，然后也不是批量的。

+]]>
+      
+        Java
+      
+      
+        Java
+        Disruptor
+      
+  
+  
+    Leetcode 155 最小栈(Min Stack) 题解分析
+    /2020/12/06/Leetcode-155-%E6%9C%80%E5%B0%8F%E6%A0%88-Min-Stack-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
+    题目介绍
Design a stack that supports push, pop, top, and retrieving the minimum element in constant time.
设计一个栈，支持压栈，出站，获取栈顶元素，通过常数级复杂度获取栈中的最小元素

+
    
+
  • push(x) – Push element x onto stack.
    • 
+
  • pop() – Removes the element on top of the stack.
    • 
+
  • top() – Get the top element.
    • 
+
  • getMin() – Retrieve the minimum element in the stack.
    • 
+

 
示例
Example 1:

 
Input
 ["MinStack","push","push","push","getMin","pop","top","getMin"]
@@ -3416,72 +3416,6 @@ Output: 0
]]>
       
         Java
-        Spring
         Mybatis
+        Spring
         Mybatis
         缓存
         Mybatis
@@ -5599,62 +5599,6 @@ REDIS_STATIC void __quicklistInsertNode(quicklist *quicklist,
         源码
       
   
-  
-    redis淘汰策略复习
-    /2021/08/01/redis%E6%B7%98%E6%B1%B0%E7%AD%96%E7%95%A5%E5%A4%8D%E4%B9%A0/
-    前面复习了 redis 的过期策略，这里再复习下淘汰策略，淘汰跟过期的区别有时候会被混淆了，过期主要针对那些设置了过期时间的 key，应该说是一种逻辑策略，是主动的还是被动的加定时的，两种有各自的取舍，而淘汰也可以看成是一种保持系统稳定的策略，因为如果内存满了，不采取任何策略处理，那大概率会导致系统故障，之前其实主要从源码角度分析过redis 的 LRU 和 LFU，但这个是偏底层的实现，抠得比较细，那么具体的系统层面的配置是有哪些策略，来看下 redis labs 的介绍

-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
PolicyDescription
noeviction                    不逐出Returns an error if the memory limit has been reached when trying to insert more data，插入更多数据时，如果内存达到上限了，返回错误
allkeys-lru                   所有的 key 使用 lru 逐出Evicts the least recently used keys out of all keys                                             在所有 key 中逐出最近最少使用的
allkeys-lfu                   所有的 key 使用 lfu 逐出Evicts the least frequently used keys out of all keys                                   在所有 key 中逐出最近最不频繁使用的
allkeys-random             所有的 key 中随机逐出Randomly evicts keys out of all keys                                                       在所有 key 中随机逐出
volatile-lruEvicts the least recently used keys out of all keys with an “expire” field set    在设置了过期时间的 key 空间 expire 中使用 lru 策略逐出
volatile-lfuEvicts the least frequently used keys out of all keys with an “expire” field set 在设置了过期时间的 key 空间 expire 中使用 lfu 策略逐出
volatile-randomRandomly evicts keys with an “expire” field set                                         在设置了过期时间的 key 空间 expire 中随机逐出
volatile-ttlEvicts the shortest time-to-live keys out of all keys with an “expire” field set.在设置了过期时间的 key 空间 expire 中逐出更早过期的

-
而在这其中默认使用的策略是 volatile-lru，对 lru 跟 lfu 想有更多的了解可以看下我之前的文章redis系列介绍八-淘汰策略

-]]>
-      
-        redis
-      
-      
-        redis
-        淘汰策略
-        应用
-        Evict
-      
-  
   
     redis数据结构介绍四-第四部分 压缩表
     /2020/01/19/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E5%9B%9B/
@@ -5711,6 +5655,62 @@ REDIS_STATIC void __quicklistInsertNode(quicklist *quicklist,
         源码
       
   
+  
+    redis淘汰策略复习
+    /2021/08/01/redis%E6%B7%98%E6%B1%B0%E7%AD%96%E7%95%A5%E5%A4%8D%E4%B9%A0/
+    前面复习了 redis 的过期策略，这里再复习下淘汰策略，淘汰跟过期的区别有时候会被混淆了，过期主要针对那些设置了过期时间的 key，应该说是一种逻辑策略，是主动的还是被动的加定时的，两种有各自的取舍，而淘汰也可以看成是一种保持系统稳定的策略，因为如果内存满了，不采取任何策略处理，那大概率会导致系统故障，之前其实主要从源码角度分析过redis 的 LRU 和 LFU，但这个是偏底层的实现，抠得比较细，那么具体的系统层面的配置是有哪些策略，来看下 redis labs 的介绍

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
PolicyDescription
noeviction                    不逐出Returns an error if the memory limit has been reached when trying to insert more data，插入更多数据时，如果内存达到上限了，返回错误
allkeys-lru                   所有的 key 使用 lru 逐出Evicts the least recently used keys out of all keys                                             在所有 key 中逐出最近最少使用的
allkeys-lfu                   所有的 key 使用 lfu 逐出Evicts the least frequently used keys out of all keys                                   在所有 key 中逐出最近最不频繁使用的
allkeys-random             所有的 key 中随机逐出Randomly evicts keys out of all keys                                                       在所有 key 中随机逐出
volatile-lruEvicts the least recently used keys out of all keys with an “expire” field set    在设置了过期时间的 key 空间 expire 中使用 lru 策略逐出
volatile-lfuEvicts the least frequently used keys out of all keys with an “expire” field set 在设置了过期时间的 key 空间 expire 中使用 lfu 策略逐出
volatile-randomRandomly evicts keys with an “expire” field set                                         在设置了过期时间的 key 空间 expire 中随机逐出
volatile-ttlEvicts the shortest time-to-live keys out of all keys with an “expire” field set.在设置了过期时间的 key 空间 expire 中逐出更早过期的

+
而在这其中默认使用的策略是 volatile-lru，对 lru 跟 lfu 想有更多的了解可以看下我之前的文章redis系列介绍八-淘汰策略

+]]>
+      
+        redis
+      
+      
+        redis
+        淘汰策略
+        应用
+        Evict
+      
+  
   
     redis系列介绍七-过期策略
     /2020/04/12/redis%E7%B3%BB%E5%88%97%E4%BB%8B%E7%BB%8D%E4%B8%83/
@@ -6707,70 +6707,6 @@ hz 10
-  
-    rust学习笔记-所有权三之切片
-    /2021/05/16/rust%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0-%E6%89%80%E6%9C%89%E6%9D%83%E4%B8%89%E4%B9%8B%E5%88%87%E7%89%87/
-    除了引用，Rust 还有另外一种不持有所有权的数据类型：切片(slice)。切片允许我们引用集合中某一段连续的元素序列，而不是整个集合。
例如代码

-
fn main() {
-    let mut s = String::from("hello world");
-
-    let word = first_word(&s);
-
-    s.clear();
-
-    // 这时候虽然 word 还是 5，但是 s 已经被清除了，所以就没存在的意义
-}

-
这里其实我们就需要关注 s 的存在性，代码的逻辑合理性就需要额外去维护，此时我们就可以用切片

-
let s = String::from("hello world")
-
-let hello = &s[0..5];
-let world = &s[6..11];

-
其实跟 Python 的list 之类的语法有点类似，当然里面还有些语法糖，比如可以直接用省略后面的数字表示直接引用到结尾

-
let hello = &s[0..];

-
甚至再进一步

-
let hello = &s[..];

-
使用了切片之后

-
fn first_word(s: &String) -> &str {
-    let bytes = s.as_bytes();
-
-    for (i, &item) in bytes.iter().enumerate() {
-        if item == b' ' {
-            return &s[0..i];
-        }
-    }
-
-    &s[..]
-}
-fn main() {
-    let mut s = String::from("hello world");
-
-    let word = first_word(&s);
-
-    s.clear(); // error!
-
-    println!("the first word is: {}", word);
-}

-
那再执行 main 函数的时候就会抛错，因为 word 还是个切片，需要保证 s 的有效性，并且其实我们可以将函数申明成

-
fn first_word(s: &str) -> &str {

-
这样就既能处理&String 的情况，就是当成完整字符串的切片，也能处理普通的切片。
其他类型的切片

-
let a = [1, 2, 3, 4, 5];
-let slice = &a[1..3];

-
简单记录下，具体可以去看看这本书

-]]>
-      
-        语言
-        Rust
-      
-      
-        Rust
-        所有权
-        内存分布
-        新语言
-        可变引用
-        不可变引用
-        切片
-      
-  
   
     rust学习笔记-所有权二
     /2021/04/18/rust%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0-%E6%89%80%E6%9C%89%E6%9D%83%E4%BA%8C/
@@ -6853,6 +6789,70 @@ hz 10
+  
+    rust学习笔记-所有权三之切片
+    /2021/05/16/rust%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0-%E6%89%80%E6%9C%89%E6%9D%83%E4%B8%89%E4%B9%8B%E5%88%87%E7%89%87/
+    除了引用，Rust 还有另外一种不持有所有权的数据类型：切片(slice)。切片允许我们引用集合中某一段连续的元素序列，而不是整个集合。
例如代码

+
fn main() {
+    let mut s = String::from("hello world");
+
+    let word = first_word(&s);
+
+    s.clear();
+
+    // 这时候虽然 word 还是 5，但是 s 已经被清除了，所以就没存在的意义
+}

+
这里其实我们就需要关注 s 的存在性，代码的逻辑合理性就需要额外去维护，此时我们就可以用切片

+
let s = String::from("hello world")
+
+let hello = &s[0..5];
+let world = &s[6..11];

+
其实跟 Python 的list 之类的语法有点类似，当然里面还有些语法糖，比如可以直接用省略后面的数字表示直接引用到结尾

+
let hello = &s[0..];

+
甚至再进一步

+
let hello = &s[..];

+
使用了切片之后

+
fn first_word(s: &String) -> &str {
+    let bytes = s.as_bytes();
+
+    for (i, &item) in bytes.iter().enumerate() {
+        if item == b' ' {
+            return &s[0..i];
+        }
+    }
+
+    &s[..]
+}
+fn main() {
+    let mut s = String::from("hello world");
+
+    let word = first_word(&s);
+
+    s.clear(); // error!
+
+    println!("the first word is: {}", word);
+}

+
那再执行 main 函数的时候就会抛错，因为 word 还是个切片，需要保证 s 的有效性，并且其实我们可以将函数申明成

+
fn first_word(s: &str) -> &str {

+
这样就既能处理&String 的情况，就是当成完整字符串的切片，也能处理普通的切片。
其他类型的切片

+
let a = [1, 2, 3, 4, 5];
+let slice = &a[1..3];

+
简单记录下，具体可以去看看这本书

+]]>
+      
+        语言
+        Rust
+      
+      
+        Rust
+        所有权
+        内存分布
+        新语言
+        可变引用
+        不可变引用
+        切片
+      
+  
   
     rust学习笔记-所有权一
     /2021/04/18/rust%E5%AD%A6%E4%B9%A0%E7%AC%94%E8%AE%B0/
@@ -7206,19 +7206,6 @@ user3:
         jvm
       
   
-  
-    上次的其他 外行聊国足
-    /2022/03/06/%E4%B8%8A%E6%AC%A1%E7%9A%84%E5%85%B6%E4%BB%96-%E5%A4%96%E8%A1%8C%E8%81%8A%E5%9B%BD%E8%B6%B3/
-    上次本来想在换车牌后面聊下这个话题，为啥要聊这个话题呢，也很简单，在地铁上看到一对猜测是情侣或者比较关系好的男女同学在聊，因为是这位男同学是大学学的工科，然后自己爱好设计绘画相关的，可能还以此赚了点钱，在地铁上讨论男的要不要好好努力把大学课程完成好，大致的观点是没必要，本来就不适合，这一段我就不说了，恋爱人的嘴，信你个鬼。
后面男的说在家里又跟他爹吵了关于男足的，估计是那次输了越南，实话说我不是个足球迷，对各方面技术相关也不熟，只是对包括这个人的解释和网上一些观点的看法，纯主观，这次地铁上这位说的大概意思是足球这个训练什么的很难的，要想赢越南也很难的，不是我们能嘴炮的；在网上看到一个赞同数很多的一个回答，说什么中国是个体育弱国，但是由于有一些乒乓球，跳水等小众项目比较厉害，让民众给误解了，首先我先来反驳下这个偷换概念的观点，第一所谓的体育弱国，跟我们觉得足球不应该这么差没半毛钱关系，因为体育弱国，我们的足球本来就不是顶尖的，也并不是去跟顶尖的球队去争，以足球为例，跟巴西，阿根廷，英国，德国，西班牙，意大利，法国这些足球强国，去比较，我相信没有一个足球迷会这么去做对比，因为我们足球历史最高排名是 1998 年的 37 名，最差是 100 名，把能数出来的强队都数完，估计都还不会到 37，所以根本没有跟强队去做对比，第二体育弱国，我们的体育投入是在逐年降低吗，我们是因战乱没法好好训练踢球？还是这帮傻逼就不争气，前面也说了我们足球世界排名最高 37，最低 100，那么前阵子我们输的越南是第几，目前我们的排名 77 名，越南 92 名，看明白了么，轮排名我们都不至于输越南，然后就是这个排名，这也是我想回应那位地铁上的兄弟，我觉得除了造核弹这种高精尖技术，绝大部分包含足球这类运动，遵循类二八原则，比如满分是 100 分，从 80 提到 90 分或者 90 分提到 100 分非常难，30 分提到 40 分，50 分提到 60 分我觉得都是可以凭后天努力达成的，基本不受天赋限制，这里可以以篮球来类比下，相对足球的确篮球没有那么火，或者行业市值没法比，但是也算是相对大众了，中国在篮球方面相对比较好一点，在 08 年奥运会冲进过八强，那也不是唯一的巅峰，但是我说这个其实是想说明两方面的事情，第一，像篮球一样，状态是有起起伏伏，排名也会变动，但是我觉得至少能维持一个相对稳定的总体排名和持平或者上升的趋势，这恰恰是我们这种所谓的“体育弱国”应该走的路线，第二就是去支持我的类二八原则的，可以看到我们的篮球这两年也很垃圾，排名跌到 29 了，那问题我觉得跟足球是一样的，就是不能脚踏实地，如斯科拉说的，中国篮球太缺少竞争，打得好不好都是这些人打，打输了还是照样拿钱，相对足球，篮球的技术我还是懂一些的，对比 08 年的中国男篮，的确像姚明跟王治郅这样的天赋型+努力型球员少了以后竞争力下降在所难免，但是去对比下基本功，传球，投篮，罚球稳定性，也完全不是一个水平的，这些就是我说的，可以通过努力训练拿 80 分的，只要拿到 80 分，甚至只要拿到 60 分，我觉得应该就还算对得起球迷了，就像 NBA 里球队也会有核心球员的更替，战绩起起伏伏，但是基本功这东西，防守积极性，我觉得不随核心球员的变化而变化，就像姚明这样的天赋，其实他应该还有一些先天缺陷，大脚趾较长等，但是他从 CBA 到 NBA，在 NBA 适应并且打成顶尖中锋，离不开刻苦训练，任何的成功都不是纯天赋的，必须要付出足够的努力。
说回足球，如果像前面那么洗地（体育弱国），那能给我维持住一个稳定的排名我也能接受，问题是我们的经济物质资源比 2000 年前应该有了质的变化，身体素质也越来越好，即使是体育弱国，这么继续走下坡路，半死不活的，不觉得是打了自己的脸么。足球也需要基本功，基本的体能，力量这些，看看现在这些国足运动员的体型，对比下女足，说实话，如果男足这些运动员都练得不错的体脂率，耐力等，成绩即使不好，也不会比现在更差。
纯主观吐槽，勿喷。

-]]>
-      
-        生活
-        运动
-      
-      
-        生活
-      
-  
   
     介绍一下 RocketMQ
     /2020/06/21/%E4%BB%8B%E7%BB%8D%E4%B8%80%E4%B8%8B-RocketMQ/
@@ -7395,53 +7382,15 @@ user3:
       
   
   
-    分享记录一下一个 git 操作方法
-    /2022/02/06/%E5%88%86%E4%BA%AB%E8%AE%B0%E5%BD%95%E4%B8%80%E4%B8%8B%E4%B8%80%E4%B8%AA-git-%E6%93%8D%E4%BD%9C%E6%96%B9%E6%B3%95/
-    前阵子一个同事因为发现某个分支上的代码好像有缺失导致无法正常运行，然后就对比了下把缺失的代码从另一个分支上拷了过来，可能有所欠考虑，不过主要是说下操作过程和最后的处理方法，这位同学的操作是改一些代码commit 一下，这样的 commit 了大概五六次，并且已经 push 到了远端，然后就在想要怎么去处理，在本地可以 reset，已经到远端了，一个很不优雅的操作就是本地 reset 了用 force push，这个当然是不可取的，然后就是 revert 了，但是又已经 commit 了好几次了，网上看了下，好像处理方法还挺成熟的，git revert 命令本质上就是一个逆向的 git cherry-pick 操作。 它将你提交中的变更的以完全相反的方式的应用到一个新创建的提交中，本质上就是撤销或者倒转。可以理解为就是提交一个反向的操作，这里其实我们可以用range revert来进行 git revert, 用法就是

-
git revert OLDER_COMMIT^..NEWER_COMMIT

-
这样就可以解决上面的问题了，但是还有个问题是这样会根据前面的 commit 数量提交对应数量个 revert commit 会显得比较乱，如果要比较干净的 commit 历史，
可以看下 git revert 命令说明

然后就可以用 -n 参数，表示不自动提交

-
git revert -n OLDER_COMMIT^..NEWER_COMMIT
-git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"

-
-
+    周末我在老丈人家打了天小工
+    /2020/08/16/%E5%91%A8%E6%9C%AB%E6%88%91%E5%9C%A8%E8%80%81%E4%B8%88%E4%BA%BA%E5%AE%B6%E6%89%93%E4%BA%86%E5%A4%A9%E5%B0%8F%E5%B7%A5/
+    这周回家提前约好了要去老丈人家帮下忙，因为在翻修下老房子，活不是特别整的那种，所以大部分都是自己干，或者找个大工临时干几天（我们这那种比较专业的泥工匠叫做大工），像我这样去帮忙的，就是干点小工（把给大工帮忙的，干些偏体力活的叫做小工）的活。从大学毕业以后真的蛮少帮家里干活了，以前上学的时候放假还是帮家里淘个米，简单的扫地拖地啥的，当然刚高考完的时候，还去我爸厂里帮忙干了几天的活，实在是比较累，不过现在想着是觉得自己那时候比较牛，而不是特别排斥这个活，相对于现在的工作来说，导致了一系列的职业病，颈椎腰背都很僵硬，眼镜也不好，还有反流，像我爸那种活反而是脑力加体力的比较好的结合。
这一天的活前半部分主要是在清理厨房，瓷砖上的油污和墙上天花板上即将脱落的石灰或者白色涂料层，这种活特别是瓷砖上的油污，之前在自己家里也干活，还是比较熟悉的，不过前面主要是LD 在干，我主要是先搞墙上和天花板上的，干活还是很需要技巧的，如果直接去铲，那基本我会变成一个灰人，而且吸一鼻子灰，老丈人比较专业，先接上软管用水冲，一冲效果特别好，有些石灰涂料层直接就冲掉了，冲完之后先用带加长杆的刀片铲铲了一圈墙面，说实话因为老房子之前租出去了，所以墙面什么的被糟蹋的比较难看，一层一层的，不过这还算还好，后面主要是天花板上的，这可难倒我了，从小我爸妈是比较把我当小孩管着，爬上爬下的基本都是我爸搞定，但是到了老丈人家也只得硬着头皮上了，爬到跳（一种建筑工地用的架子）上，还有点晃，小心脏扑通扑通跳，而且带加长杆的铲子还是比较重的，铲一会手也有点累，不过坚持着铲完了，上面还是比较平整的，不过下来的时候又把我难住了🤦‍♂️，往下爬的时候有根杆子要跨过去，由于裤子比较紧，强行一把跨过去怕抽筋，所以以一个非常尴尬的姿势停留休息了一会，再跨了过去，幸好事后问 LD，他们都没看到，哈哈哈，然后就是帮忙一起搞瓷砖上的油污，这个太有经验了，不过老丈人更有意思，一会试试啤酒，一会用用沙子，后面在午饭前基本就弄的比较干净了，就坐着等吃饭了，下午午休了会，就继续干活了。
下午是我这次体验的重点了，因为要清理以前贴的墙纸，真的是个很麻烦的活，只能说贴墙纸的师傅活干得太好了，基本不可能整个撕下来，想用铲子一点点铲下来也不行，太轻了就只铲掉表面一层，太重了就把墙纸跟墙面的石灰啥的整个铲下来了，而且手又累又酸，后来想着是不是继续用水冲一下，对着一小面墙试验了下，效果还不错，但是又发现了个问题，那一面墙又有一块是后面糊上去的，铲掉外层的石灰后不平，然后就是最最重头的，也是让我后遗症持续到第二天的，要把那一块糊上去的水泥敲下来，毛估下大概是敲了80%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。

 ]]>
       
-        git
-        小技巧
-      
-      
-        git
-      
-  
-  
-    分享记录一下一个 scp 操作方法
-    /2022/02/06/%E5%88%86%E4%BA%AB%E8%AE%B0%E5%BD%95%E4%B8%80%E4%B8%8B%E4%B8%80%E4%B8%AA-scp-%E6%93%8D%E4%BD%9C%E6%96%B9%E6%B3%95/
-    scp 是个在服务器之间拷贝文件的一个常用命令，有时候有个场景是比如我们需要拷贝一些带有共同前缀的文件，但是有一个问题是比如我们有使用 zsh 的话，会出现一个报错，

-
zsh: no matches found: root@100.100.100.100://root/prefix*

-
这里就比较奇怪了，这个前缀的文件肯定是有的，这里其实是由于 zsh 会对 * 进行展开，这个可以在例如 ls 命令在使用中就可以发现 zsh 有这个特性
需要使用双引号或单引号将路径包起来或者在*之前加反斜杠\来阻止对*展开和转义

-
scp root@100.100.100.100://root/prefix* .

-
通过使用双引号"进行转义

-
scp root@100.100.100.100:"//root/prefix*" .

-
或者可以将 shell 从 zsh 切换成 bash

-]]>
-      
-        shell
-        小技巧
-      
-      
-        scp
-      
-  
-  
-    周末我在老丈人家打了天小工
-    /2020/08/16/%E5%91%A8%E6%9C%AB%E6%88%91%E5%9C%A8%E8%80%81%E4%B8%88%E4%BA%BA%E5%AE%B6%E6%89%93%E4%BA%86%E5%A4%A9%E5%B0%8F%E5%B7%A5/
-    这周回家提前约好了要去老丈人家帮下忙，因为在翻修下老房子，活不是特别整的那种，所以大部分都是自己干，或者找个大工临时干几天（我们这那种比较专业的泥工匠叫做大工），像我这样去帮忙的，就是干点小工（把给大工帮忙的，干些偏体力活的叫做小工）的活。从大学毕业以后真的蛮少帮家里干活了，以前上学的时候放假还是帮家里淘个米，简单的扫地拖地啥的，当然刚高考完的时候，还去我爸厂里帮忙干了几天的活，实在是比较累，不过现在想着是觉得自己那时候比较牛，而不是特别排斥这个活，相对于现在的工作来说，导致了一系列的职业病，颈椎腰背都很僵硬，眼镜也不好，还有反流，像我爸那种活反而是脑力加体力的比较好的结合。
这一天的活前半部分主要是在清理厨房，瓷砖上的油污和墙上天花板上即将脱落的石灰或者白色涂料层，这种活特别是瓷砖上的油污，之前在自己家里也干活，还是比较熟悉的，不过前面主要是LD 在干，我主要是先搞墙上和天花板上的，干活还是很需要技巧的，如果直接去铲，那基本我会变成一个灰人，而且吸一鼻子灰，老丈人比较专业，先接上软管用水冲，一冲效果特别好，有些石灰涂料层直接就冲掉了，冲完之后先用带加长杆的刀片铲铲了一圈墙面，说实话因为老房子之前租出去了，所以墙面什么的被糟蹋的比较难看，一层一层的，不过这还算还好，后面主要是天花板上的，这可难倒我了，从小我爸妈是比较把我当小孩管着，爬上爬下的基本都是我爸搞定，但是到了老丈人家也只得硬着头皮上了，爬到跳（一种建筑工地用的架子）上，还有点晃，小心脏扑通扑通跳，而且带加长杆的铲子还是比较重的，铲一会手也有点累，不过坚持着铲完了，上面还是比较平整的，不过下来的时候又把我难住了🤦‍♂️，往下爬的时候有根杆子要跨过去，由于裤子比较紧，强行一把跨过去怕抽筋，所以以一个非常尴尬的姿势停留休息了一会，再跨了过去，幸好事后问 LD，他们都没看到，哈哈哈，然后就是帮忙一起搞瓷砖上的油污，这个太有经验了，不过老丈人更有意思，一会试试啤酒，一会用用沙子，后面在午饭前基本就弄的比较干净了，就坐着等吃饭了，下午午休了会，就继续干活了。
下午是我这次体验的重点了，因为要清理以前贴的墙纸，真的是个很麻烦的活，只能说贴墙纸的师傅活干得太好了，基本不可能整个撕下来，想用铲子一点点铲下来也不行，太轻了就只铲掉表面一层，太重了就把墙纸跟墙面的石灰啥的整个铲下来了，而且手又累又酸，后来想着是不是继续用水冲一下，对着一小面墙试验了下，效果还不错，但是又发现了个问题，那一面墙又有一块是后面糊上去的，铲掉外层的石灰后不平，然后就是最最重头的，也是让我后遗症持续到第二天的，要把那一块糊上去的水泥敲下来，毛估下大概是敲了80%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。

-]]>
-      
-        生活
-        运动
-        跑步
-        干活
+        生活
+        运动
+        跑步
+        干活
       
       
         生活
@@ -7491,6 +7440,19 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"跑步
       
   
-  
-    搬运两个 StackOverflow 上的 Mysql 编码相关的问题解答
-    /2022/01/16/%E6%90%AC%E8%BF%90%E4%B8%A4%E4%B8%AA-StackOverflow-%E4%B8%8A%E7%9A%84-Mysql-%E7%BC%96%E7%A0%81%E7%9B%B8%E5%85%B3%E7%9A%84%E9%97%AE%E9%A2%98%E8%A7%A3%E7%AD%94/
-    Mysql 字符编码和排序规则
这个一直是属于一知半解的状态，知道 utf8 跟 utf8mb4 的区别主要是能不能支持 emoji，但是具体后面配置的排序规则是用来干嘛，或者有什么区别，应该使用哪个，所以在 stackoverflow 上找了下，有两个比较不错的解答，就搬过来并且配合机翻做了点修改

-
原文
For those people still arriving at this question in 2020 or later, there are newer options that may be better than both of these. For example, utf8mb4_0900_ai_ci.

-
All these collations are for the UTF-8 character encoding. The differences are in how text is sorted and compared.

-
_unicode_ci and _general_ci are two different sets of rules for sorting and comparing text according to the way we expect. Newer versions of MySQL introduce new sets of rules, too, such as _0900_ai_ci for equivalent rules based on Unicode 9.0 - and with no equivalent _general_ci variant. People reading this now should probably use one of these newer collations instead of either _unicode_ci or _general_ci. The description of those older collations below is provided for interest only.

-
MySQL is currently transitioning away from an older, flawed UTF-8 implementation. For now, you need to use utf8mb4 instead of utf8 for the character encoding part, to ensure you are getting the fixed version. The flawed version remains for backward compatibility, though it is being deprecated.

-
Key differences

-
utf8mb4_unicode_ci is based on the official Unicode rules for universal sorting and comparison, which sorts accurately in a wide range of languages.

-
utf8mb4_general_ci is a simplified set of sorting rules which aims to do as well as it can while taking many short-cuts designed to improve speed. It does not follow the Unicode rules and will result in undesirable sorting or comparison in some situations, such as when using particular languages or characters.

-
On modern servers, this performance boost will be all but negligible. It was devised in a time when servers had a tiny fraction of the CPU performance of today’s computers.

-
Benefits of utf8mb4_unicode_ci over utf8mb4_general_ci

-
utf8mb4_unicode_ci, which uses the Unicode rules for sorting and comparison, employs a fairly complex algorithm for correct sorting in a wide range of languages and when using a wide range of special characters. These rules need to take into account language-specific conventions; not everybody sorts their characters in what we would call ‘alphabetical order’.

-
As far as Latin (ie “European”) languages go, there is not much difference between the Unicode sorting and the simplified utf8mb4_general_cisorting in MySQL, but there are still a few differences:

-
For examples, the Unicode collation sorts “ß” like “ss”, and “Œ” like “OE” as people using those characters would normally want, whereas utf8mb4_general_cisorts them as single characters (presumably like “s” and “e” respectively).

-
Some Unicode characters are defined as ignorable, which means they shouldn’t count toward the sort order and the comparison should move on to the next character instead. utf8mb4_unicode_cihandles these properly.

-
In non-latin languages, such as Asian languages or languages with different alphabets, there may be a lot more differences between Unicode sorting and the simplified utf8mb4_general_cisorting. The suitability of utf8mb4_general_ciwill depend heavily on the language used. For some languages, it’ll be quite inadequate.

-
What should you use?

-
There is almost certainly no reason to use utf8mb4_general_cianymore, as we have left behind the point where CPU speed is low enough that the performance difference would be important. Your database will almost certainly be limited by other bottlenecks than this.

-
In the past, some people recommended to use utf8mb4_general_ciexcept when accurate sorting was going to be important enough to justify the performance cost. Today, that performance cost has all but disappeared, and developers are treating internationalization more seriously.

-
There’s an argument to be made that if speed is more important to you than accuracy, you may as well not do any sorting at all. It’s trivial to make an algorithm faster if you do not need it to be accurate. So, utf8mb4_general_ciis a compromise that’s probably not needed for speed reasons and probably also not suitable for accuracy reasons.

-
One other thing I’ll add is that even if you know your application only supports the English language, it may still need to deal with people’s names, which can often contain characters used in other languages in which it is just as important to sort correctly. Using the Unicode rules for everything helps add peace of mind that the very smart Unicode people have worked very hard to make sorting work properly.

-
What the parts mean

-
Firstly, ci is for case-insensitive sorting and comparison. This means it’s suitable for textual data, and case is not important. The other types of collation are cs (case-sensitive) for textual data where case is important, and bin, for where the encoding needs to match, bit for bit, which is suitable for fields which are really encoded binary data (including, for example, Base64). Case-sensitive sorting leads to some weird results and case-sensitive comparison can result in duplicate values differing only in letter case, so case-sensitive collations are falling out of favor for textual data - if case is significant to you, then otherwise ignorable punctuation and so on is probably also significant, and a binary collation might be more appropriate.

-
Next, unicode or general refers to the specific sorting and comparison rules - in particular, the way text is normalized or compared. There are many different sets of rules for the utf8mb4 character encoding, with unicode and general being two that attempt to work well in all possible languages rather than one specific one. The differences between these two sets of rules are the subject of this answer. Note that unicode uses rules from Unicode 4.0. Recent versions of MySQL add the rulesets unicode_520 using rules from Unicode 5.2, and 0900 (dropping the “unicode_” part) using rules from Unicode 9.0.

-
And lastly, utf8mb4 is of course the character encoding used internally. In this answer I’m talking only about Unicode based encodings.

-
翻译
对于那些在 2020 年或之后仍会遇到这个问题的人，有可能比这两个更好的新选项。例如，utf8mb4_0900_ai_ci。

-
所有这些排序规则都用于 UTF-8 字符编码。不同之处在于文本的排序和比较方式。

-
_unicode_ci和 _general_ci是两组不同的规则，用于按照我们期望的方式对文本进行排序和比较。较新版本的 MySQL 也引入了新的规则集，例如 _0900_ai_ci用于基于 Unicode 9.0 的等效规则 - 并且没有等效的 _general_ci变体。现在阅读本文的人可能应该使用这些较新的排序规则之一，而不是 _unicode_ci或 _general_ci。下面对那些较旧的排序规则的描述仅供参考。

-
MySQL 目前正在从旧的、有缺陷的 UTF-8 实现过渡。现在，您需要使用 utf8mb4 而不是 utf8作为字符编码部分，以确保您获得的是固定版本。有缺陷的版本仍然是为了向后兼容，尽管它已被弃用。

-
主要区别

-
utf8mb4_unicode_ci基于官方 Unicode 规则进行通用排序和比较，可在多种语言中准确排序。

-
utf8mb4_general_ci是一组简化的排序规则，旨在尽其所能，同时采用许多旨在提高速度的捷径。它不遵循 Unicode 规则，并且在某些情况下会导致不希望的排序或比较，例如在使用特定语言或字符时。

-
在现代服务器上，这种性能提升几乎可以忽略不计。它是在服务器的 CPU 性能只有当今计算机的一小部分时设计的。

-
utf8mb4_unicode_ci 相对于 utf8mb4_general_ci的优势

-
utf8mb4_unicode_ci使用 Unicode 规则进行排序和比较，采用相当复杂的算法在多种语言中以及在使用多种特殊字符时进行正确排序。这些规则需要考虑特定语言的约定；不是每个人都按照我们所说的“字母顺序”对他们的字符进行排序。

-
就拉丁语（即“欧洲”）语言而言，Unicode 排序和 MySQL 中简化的 utf8mb4_general_ci排序没有太大区别，但仍有一些区别：

-
例如，Unicode 排序规则将“ß”排序为“ss”，将“Œ”排序为“OE”，因为使用这些字符的人通常需要这些字符，而 utf8mb4_general_ci将它们排序为单个字符（大概分别像“s”和“e” ）。

-
一些 Unicode 字符被定义为可忽略，这意味着它们不应该计入排序顺序，并且比较应该转到下一个字符。 utf8mb4_unicode_ci正确处理这些。

-
在非拉丁语言中，例如亚洲语言或具有不同字母的语言，Unicode 排序和简化的 utf8mb4_general_ci排序之间可能存在更多差异。 utf8mb4_general_ci的适用性在很大程度上取决于所使用的语言。对于某些语言，这将是非常不充分的。

-
你应该用什么？

-
几乎可以肯定没有理由再使用 utf8mb4_general_ci，因为我们已经将 CPU 速度低到会严重影响性能表现的时代远抛在脑后了。您的数据库几乎肯定会受到除此之外的其他瓶颈的限制。

-
过去，有些人建议使用 utf8mb4_general_ci，除非准确排序足够重要以证明性能成本是合理的。如今，这种性能成本几乎消失了，开发人员正在更加认真地对待国际化。

-
有一个论点是，如果速度对您来说比准确性更重要，那么您可能根本不进行任何排序。如果您不需要准确的算法，那么使算法更快是微不足道的。因此，utf8mb4_general_ci是一种折衷方案，出于速度原因可能不需要，也可能出于准确性原因也不适合。

-
我要补充的另一件事是，即使您知道您的应用程序仅支持英语，它可能仍需要处理人名，这些人名通常包含其他语言中使用的字符，在这些语言中正确排序同样重要.对所有事情都使用 Unicode 规则有助于让您更加安心，因为非常聪明的 Unicode 人员已经非常努力地工作以使排序正常工作。

-
其余各个部分是什么意思

-
首先， ci 用于不区分大小写的排序和比较。这意味着它适用于文本数据，大小写并不重要。其他类型的排序规则是 cs（区分大小写），用于区分大小写的文本数据，以及 bin，用于编码需要匹配的地方，逐位匹配，适用于真正编码二进制数据的字段（包括，用于例如，Base64）。区分大小写的排序会导致一些奇怪的结果，区分大小写的比较可能会导致重复值仅在字母大小写上有所不同，因此区分大小写的排序规则对文本数据不受欢迎 - 如果大小写对您很重要，那么标点符号就可以忽略等等可能也很重要，二进制排序规则可能更合适。

-
接下来，unicode 或general 指的是具体的排序和比较规则——特别是文本被规范化或比较的方式。 utf8mb4 字符编码有许多不同的规则集，其中 unicode 和 general 是两种，它们试图在所有可能的语言中都很好地工作，而不是在一种特定的语言中。这两组规则之间的差异是此答案的主题。请注意，unicode 使用 Unicode 4.0 中的规则。 MySQL 的最新版本使用 Unicode 5.2 的规则添加规则集 unicode_520，使用 Unicode 9.0 的规则添加 0900（删除“unicode_”部分）。

-
最后，utf8mb4 当然是内部使用的字符编码。在这个答案中，我只谈论基于 Unicode 的编码。

-
utf8 和 utf8mb4 编码有什么区别
原文
UTF-8is a variable-length encoding. In the case of UTF-8, this means that storing one code point requires one to four bytes. However, MySQL’s encoding called “utf8” (alias of “utf8mb3”) only stores a maximum of three bytes per code point.

-
So the character set “utf8”/“utf8mb3” cannot store all Unicode code points: it only supports the range 0x000 to 0xFFFF, which is called the “Basic Multilingual Plane“. See also Comparison of Unicode encodings.

-
This is what (a previous version of the same page at)the MySQL documentationhas to say about it:

-

-
The character set named utf8[/utf8mb3] uses a maximum of three bytes per character and contains only BMP characters. As of MySQL 5.5.3, the utf8mb4 character set uses a maximum of four bytes per character supports supplemental characters:

-
    
-
  • For a BMP character, utf8[/utf8mb3] and utf8mb4 have identical storage characteristics: same code values, same encoding, same length.
    • 
-
  • For a supplementary character, utf8[/utf8mb3] cannot store the character at all, while utf8mb4 requires four bytes to store it. Since utf8[/utf8mb3] cannot store the character at all, you do not have any supplementary characters in utf8[/utf8mb3] columns and you need not worry about converting characters or losing data when upgrading utf8[/utf8mb3] data from older versions of MySQL.
    • 
-

-

-
So if you want your column to support storing characters lying outside the BMP (and you usually want to), such as emoji, use “utf8mb4”. See also What are the most common non-BMP Unicode characters in actual use?.

-
译文
UTF-8 是一种可变长度编码。对于 UTF-8，这意味着存储一个代码点需要一到四个字节。但是，MySQL 的编码称为“utf8”（“utf8mb3”的别名）每个代码点最多只能存储三个字节。

-
所以字符集“utf8”/“utf8mb3”不能存储所有的Unicode码位：它只支持0x000到0xFFFF的范围，被称为“基本多语言平面”。另请参阅 Unicode 编码比较。

-
这就是（同一页面的先前版本）MySQL 文档 不得不说的：

-

-
名为 utf8[/utf8mb3] 的字符集每个字符最多使用三个字节，并且仅包含 BMP 字符。从 MySQL 5.5.3 开始，utf8mb4 字符集每个字符最多使用四个字节，支持补充字符：

-
    
-
  • 对于 BMP 字符，utf8[/utf8mb3] 和 utf8mb4 具有相同的存储特性：相同的代码值、相同的编码、相同的长度。
    • 
-
  • 对于补充字符，utf8[/utf8mb3] 根本无法存储该字符，而 utf8mb4 需要四个字节来存储它。由于 utf8[/utf8mb3] 根本无法存储字符，因此您在 utf8[/utf8mb3] 列中没有任何补充字符，您不必担心从旧版本升级 utf8[/utf8mb3] 数据时转换字符或丢失数据mysql。
    • 
-

-

-
因此，如果您希望您的列支持存储位于 BMP 之外的字符（并且您通常希望这样做），例如 emoji，请使用“utf8mb4”。另请参阅

-
实际使用中最常见的非 BMP Unicode 字符是什么？ 。

-]]>
-      
-        Mysql
-      
-      
-        mysql
-        字符集
-        编码
-        utf8
-        utf8mb4
-        utf8mb4_0900_ai_ci
-        utf8mb4_unicode_ci
-        utf8mb4_general_ci
-      
-  
   
     看完了扫黑风暴,聊聊感想
     /2021/10/24/%E7%9C%8B%E5%AE%8C%E4%BA%86%E6%89%AB%E9%BB%91%E9%A3%8E%E6%9A%B4-%E8%81%8A%E8%81%8A%E6%84%9F%E6%83%B3/
@@ -7658,17 +7532,41 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"git revert OLDER_COMMIT^..NEWER_COMMIT

+
这样就可以解决上面的问题了，但是还有个问题是这样会根据前面的 commit 数量提交对应数量个 revert commit 会显得比较乱，如果要比较干净的 commit 历史，
可以看下 git revert 命令说明

然后就可以用 -n 参数，表示不自动提交

+
git revert -n OLDER_COMMIT^..NEWER_COMMIT
+git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"

+
+
 ]]>
       
-        生活
+        git
+        小技巧
       
       
-        生活
+        git
+      
+  
+  
+    分享记录一下一个 scp 操作方法
+    /2022/02/06/%E5%88%86%E4%BA%AB%E8%AE%B0%E5%BD%95%E4%B8%80%E4%B8%8B%E4%B8%80%E4%B8%AA-scp-%E6%93%8D%E4%BD%9C%E6%96%B9%E6%B3%95/
+    scp 是个在服务器之间拷贝文件的一个常用命令，有时候有个场景是比如我们需要拷贝一些带有共同前缀的文件，但是有一个问题是比如我们有使用 zsh 的话，会出现一个报错，

+
zsh: no matches found: root@100.100.100.100://root/prefix*

+
这里就比较奇怪了，这个前缀的文件肯定是有的，这里其实是由于 zsh 会对 * 进行展开，这个可以在例如 ls 命令在使用中就可以发现 zsh 有这个特性
需要使用双引号或单引号将路径包起来或者在*之前加反斜杠\来阻止对*展开和转义

+
scp root@100.100.100.100://root/prefix* .

+
通过使用双引号"进行转义

+
scp root@100.100.100.100:"//root/prefix*" .

+
或者可以将 shell 从 zsh 切换成 bash

+]]>
+      
+        shell
+        小技巧
+      
+      
+        scp
       
   
   
@@ -10078,248 +9976,66 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"@Configuration
-@ConditionalOnClass({ EnableAspectJAutoProxy.class, Aspect.class, Advice.class })
-@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
-public class AopAutoConfiguration {
-
-	@Configuration
-	@EnableAspectJAutoProxy(proxyTargetClass = false)
-	@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false", matchIfMissing = true)
-	public static class JdkDynamicAutoProxyConfiguration {
-	}
-
-	@Configuration
-	@EnableAspectJAutoProxy(proxyTargetClass = true)
-	@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true", matchIfMissing = false)
-	public static class CglibAutoProxyConfiguration {
-	}
+    聊一下 SpringBoot 中动态切换数据源的方法
+    /2021/09/26/%E8%81%8A%E4%B8%80%E4%B8%8B-SpringBoot-%E4%B8%AD%E5%8A%A8%E6%80%81%E5%88%87%E6%8D%A2%E6%95%B0%E6%8D%AE%E6%BA%90%E7%9A%84%E6%96%B9%E6%B3%95/
+    其实这个表示有点不太对，应该是 Druid 动态切换数据源的方法，只是应用在了 springboot 框架中，准备代码准备了半天，之前在一次数据库迁移中使用了，发现 Druid 还是很强大的，用来做动态数据源切换很方便。

+
首先这里的场景跟我原来用的有点点区别，在项目中使用的是通过配置中心控制数据源切换，统一切换，而这里的例子多加了个可以根据接口注解配置

+
第一部分是最核心的，如何基于 Spring JDBC 和 Druid 来实现数据源切换，是继承了org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource 这个类，他的determineCurrentLookupKey方法会被调用来获得用来决定选择那个数据源的对象，也就是 lookupKey，也可以通过这个类看到就是通过这个 lookupKey 来路由找到数据源。

+
public class DynamicDataSource extends AbstractRoutingDataSource {
 
-}

+    @Override
+    protected Object determineCurrentLookupKey() {
+        if (DatabaseContextHolder.getDatabaseType() != null) {
+            return DatabaseContextHolder.getDatabaseType().getName();
+        }
+        return DatabaseType.MASTER1.getName();
+    }
+}

 
-
而在 2.x 中变成了这样

-
@Configuration(proxyBeanMethods = false)
-@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
-public class AopAutoConfiguration {
+
而如何使用这个 lookupKey 呢，就涉及到我们的 DataSource 配置了，原来就是我们可以直接通过spring 的 jdbc 配置数据源，像这样

+

+
现在我们要使用 Druid 作为数据源了，然后配置 DynamicDataSource 的参数，通过 key 来选择对应的 DataSource，也就是下面配的 master1 和 master2

+
<bean id="master1" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
+          destroy-method="close"
+          p:driverClassName="com.mysql.cj.jdbc.Driver"
+          p:url="${master1.demo.datasource.url}"
+          p:username="${master1.demo.datasource.username}"
+          p:password="${master1.demo.datasource.password}"
+          p:initialSize="5"
+          p:minIdle="1"
+          p:maxActive="10"
+          p:maxWait="60000"
+          p:timeBetweenEvictionRunsMillis="60000"
+          p:minEvictableIdleTimeMillis="300000"
+          p:validationQuery="SELECT 'x'"
+          p:testWhileIdle="true"
+          p:testOnBorrow="false"
+          p:testOnReturn="false"
+          p:poolPreparedStatements="false"
+          p:maxPoolPreparedStatementPerConnectionSize="20"
+          p:connectionProperties="config.decrypt=true"
+          p:filters="stat,config"/>
 
-	@Configuration(proxyBeanMethods = false)
-	@ConditionalOnClass(Advice.class)
-	static class AspectJAutoProxyingConfiguration {
-
-		@Configuration(proxyBeanMethods = false)
-		@EnableAspectJAutoProxy(proxyTargetClass = false)
-		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false")
-		static class JdkDynamicAutoProxyConfiguration {
-
-		}
-
-		@Configuration(proxyBeanMethods = false)
-		@EnableAspectJAutoProxy(proxyTargetClass = true)
-		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
-				matchIfMissing = true)
-		static class CglibAutoProxyConfiguration {
-
-		}
-
-	}

-
-
为何会加载 AopAutoConfiguration 在前面的文章聊聊 SpringBoot 自动装配里已经介绍过，有兴趣的可以看下，可以发现 springboot 在 2.x 版本开始使用 cglib 作为默认的动态代理实现。

-
然后就是出现的问题了，代码是这样的，一个简单的基于 springboot 的带有数据库的插入，对插入代码加了事务注解，

-
@Mapper
-public interface StudentMapper {
-		// 就是插入一条数据
-    @Insert("insert into student(name, age)" + "values ('nick', '18')")
-    public Long insert();
-}
-
-@Component
-public class StudentManager {
-
-    @Resource
-    private StudentMapper studentMapper;
-    
-    public Long createStudent() {
-        return studentMapper.insert();
-    }
-}
-
-@Component
-public class StudentServiceImpl implements StudentService {
-
-    @Resource
-    private StudentManager studentManager;
-
-    // 自己引用
-    @Resource
-    private StudentServiceImpl studentService;
-
-    @Override
-    @Transactional
-    public Long createStudent() {
-        Long id = studentManager.createStudent();
-        Long id2 = studentService.createStudent2();
-        return 1L;
-    }
-
-    @Transactional
-    private Long createStudent2() {
-//        Integer t = Integer.valueOf("aaa");
-        return studentManager.createStudent();
-    }
-}

-
-
第一个公有方法 createStudent 首先调用了 manager 层的创建方法，然后再通过引入的 studentService 调用了createStudent2，我们先跑一下看看会出现啥情况，果不其然报错了，正是这个报错让我纠结了很久

-
EdR7oB

-
报了个空指针，而且是在 createStudent2 已经被调用到了，在它的内部，报的 studentManager 是 null，首先 cglib 作为动态代理它是通过继承的方式来实现的，相当于是会在调用目标对象的代理方法时调用 cglib 生成的子类，具体的代理切面逻辑在子类实现，然后在调用目标对象的目标方法，但是继承的方式对于 final 和私有方法其实是没法进行代理的，因为没法继承，所以我最开始的想法是应该通过 studentService 调用 createStudent2 的时候就报错了，也就是不会进入这个方法内部，后面才发现犯了个特别二的错误，继承的方式去调用父类的私有方法，对于 Java 来说是可以调用到的，父类的私有方法并不由子类的InstanceKlass维护，只能通过子类的InstanceKlass找到Java类对应的_super，这样间接地访问。也就是说子类其实是可以访问的，那为啥访问了会报空指针呢，这里报的是studentManager 是空的，可以往依赖注入方面去想，如果忽略依赖注入，我这个studentManager 的确是 null，那是不是就没有被依赖注入呢，但是为啥前面那个可以呢

-
这个问题着实查了很久，不废话来看代码

-
@Override
-		protected Object invokeJoinpoint() throws Throwable {
-			if (this.methodProxy != null) {
-        // 这里的 target 就是被代理的 bean
-				return this.methodProxy.invoke(this.target, this.arguments);
-			}
-			else {
-				return super.invokeJoinpoint();
-			}
-		}

-
-
-
-
这个是org.springframework.aop.framework.CglibAopProxy.CglibMethodInvocation的代码，其实它在这里不是直接调用 super 也就是父类的方法，而是通过 methodProxy 调用 target 目标对象的方法，也就是原始的 studentService bean 的方法，这样子 spring 管理的已经做好依赖注入的 bean 就能正常起作用，否则就会出现上面的问题，因为 cglib 其实是通过继承来实现，通过将调用转移到子类上加入代理逻辑，我们在简单使用的时候会直接 invokeSuper() 调用父类的方法，但是在这里 spring 的场景里需要去支持 spring 的功能逻辑，所以上面的问题就可以开始来解释了，因为 createStudent 是公共方法，cglib 可以对其进行继承代理，但是在执行逻辑的时候其实是通过调用目标对象，也就是 spring 管理的被代理的目标对象的 bean 调用的 createStudent，而对于下面的 createStudent2 方法因为是私有方法，不会走代理逻辑，也就不会有调用回目标对象的逻辑，只是通过继承关系，在子类中没有这个方法，所以会通过子类的InstanceKlass找到这个类对应的_super，然后调用父类的这个私有方法，这里要搞清楚一个点，从这个代理类直接找到其父类然后调用这个私有方法，这个类是由 cglib 生成的，不是被 spring 管理起来经过依赖注入的 bean，所以是没有 studentManager 这个依赖的，也就出现了前面的问题

-
而在前面提到的cglib通过methodProxy调用到目标对象，目标对象是在什么时候设置的呢，其实是在bean的生命周期中，org.springframework.beans.factory.config.BeanPostProcessor#postProcessAfterInitialization这个接口的在bean的初始化过程中，会调用实现了这个接口的方法，

-
@Override
-public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
-	if (bean != null) {
-		Object cacheKey = getCacheKey(bean.getClass(), beanName);
-		if (this.earlyProxyReferences.remove(cacheKey) != bean) {
-			return wrapIfNecessary(bean, beanName, cacheKey);
-		}
-	}
-	return bean;
-}

-
-
具体的逻辑在 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#wrapIfNecessary这个方法里

-
protected Object getCacheKey(Class<?> beanClass, @Nullable String beanName) {
-		if (StringUtils.hasLength(beanName)) {
-			return (FactoryBean.class.isAssignableFrom(beanClass) ?
-					BeanFactory.FACTORY_BEAN_PREFIX + beanName : beanName);
-		}
-		else {
-			return beanClass;
-		}
-	}
-
-	/**
-	 * Wrap the given bean if necessary, i.e. if it is eligible for being proxied.
-	 * @param bean the raw bean instance
-	 * @param beanName the name of the bean
-	 * @param cacheKey the cache key for metadata access
-	 * @return a proxy wrapping the bean, or the raw bean instance as-is
-	 */
-	protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
-		if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
-			return bean;
-		}
-		if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
-			return bean;
-		}
-		if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
-			this.advisedBeans.put(cacheKey, Boolean.FALSE);
-			return bean;
-		}
-
-		// Create proxy if we have advice.
-		Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
-		if (specificInterceptors != DO_NOT_PROXY) {
-			this.advisedBeans.put(cacheKey, Boolean.TRUE);
-			Object proxy = createProxy(
-					bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
-			this.proxyTypes.put(cacheKey, proxy.getClass());
-			return proxy;
-		}
-
-		this.advisedBeans.put(cacheKey, Boolean.FALSE);
-		return bean;
-	}

-
-
然后在 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#createProxy 中创建了代理类

-]]>
-      
-        Java
-        SpringBoot
-      
-      
-        Java
-        Spring
-        SpringBoot
-        cglib
-        事务
-      
-  
-  
-    聊一下 SpringBoot 中动态切换数据源的方法
-    /2021/09/26/%E8%81%8A%E4%B8%80%E4%B8%8B-SpringBoot-%E4%B8%AD%E5%8A%A8%E6%80%81%E5%88%87%E6%8D%A2%E6%95%B0%E6%8D%AE%E6%BA%90%E7%9A%84%E6%96%B9%E6%B3%95/
-    其实这个表示有点不太对，应该是 Druid 动态切换数据源的方法，只是应用在了 springboot 框架中，准备代码准备了半天，之前在一次数据库迁移中使用了，发现 Druid 还是很强大的，用来做动态数据源切换很方便。

-
首先这里的场景跟我原来用的有点点区别，在项目中使用的是通过配置中心控制数据源切换，统一切换，而这里的例子多加了个可以根据接口注解配置

-
第一部分是最核心的，如何基于 Spring JDBC 和 Druid 来实现数据源切换，是继承了org.springframework.jdbc.datasource.lookup.AbstractRoutingDataSource 这个类，他的determineCurrentLookupKey方法会被调用来获得用来决定选择那个数据源的对象，也就是 lookupKey，也可以通过这个类看到就是通过这个 lookupKey 来路由找到数据源。

-
public class DynamicDataSource extends AbstractRoutingDataSource {
-
-    @Override
-    protected Object determineCurrentLookupKey() {
-        if (DatabaseContextHolder.getDatabaseType() != null) {
-            return DatabaseContextHolder.getDatabaseType().getName();
-        }
-        return DatabaseType.MASTER1.getName();
-    }
-}

-
-
而如何使用这个 lookupKey 呢，就涉及到我们的 DataSource 配置了，原来就是我们可以直接通过spring 的 jdbc 配置数据源，像这样

-

-
现在我们要使用 Druid 作为数据源了，然后配置 DynamicDataSource 的参数，通过 key 来选择对应的 DataSource，也就是下面配的 master1 和 master2

-
<bean id="master1" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
-          destroy-method="close"
-          p:driverClassName="com.mysql.cj.jdbc.Driver"
-          p:url="${master1.demo.datasource.url}"
-          p:username="${master1.demo.datasource.username}"
-          p:password="${master1.demo.datasource.password}"
-          p:initialSize="5"
-          p:minIdle="1"
-          p:maxActive="10"
-          p:maxWait="60000"
-          p:timeBetweenEvictionRunsMillis="60000"
-          p:minEvictableIdleTimeMillis="300000"
-          p:validationQuery="SELECT 'x'"
-          p:testWhileIdle="true"
-          p:testOnBorrow="false"
-          p:testOnReturn="false"
-          p:poolPreparedStatements="false"
-          p:maxPoolPreparedStatementPerConnectionSize="20"
-          p:connectionProperties="config.decrypt=true"
-          p:filters="stat,config"/>
-
-    <bean id="master2" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
-          destroy-method="close"
-          p:driverClassName="com.mysql.cj.jdbc.Driver"
-          p:url="${master2.demo.datasource.url}"
-          p:username="${master2.demo.datasource.username}"
-          p:password="${master2.demo.datasource.password}"
-          p:initialSize="5"
-          p:minIdle="1"
-          p:maxActive="10"
-          p:maxWait="60000"
-          p:timeBetweenEvictionRunsMillis="60000"
-          p:minEvictableIdleTimeMillis="300000"
-          p:validationQuery="SELECT 'x'"
-          p:testWhileIdle="true"
-          p:testOnBorrow="false"
-          p:testOnReturn="false"
-          p:poolPreparedStatements="false"
-          p:maxPoolPreparedStatementPerConnectionSize="20"
-          p:connectionProperties="config.decrypt=true"
-          p:filters="stat,config"/>
+    <bean id="master2" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
+          destroy-method="close"
+          p:driverClassName="com.mysql.cj.jdbc.Driver"
+          p:url="${master2.demo.datasource.url}"
+          p:username="${master2.demo.datasource.username}"
+          p:password="${master2.demo.datasource.password}"
+          p:initialSize="5"
+          p:minIdle="1"
+          p:maxActive="10"
+          p:maxWait="60000"
+          p:timeBetweenEvictionRunsMillis="60000"
+          p:minEvictableIdleTimeMillis="300000"
+          p:validationQuery="SELECT 'x'"
+          p:testWhileIdle="true"
+          p:testOnBorrow="false"
+          p:testOnReturn="false"
+          p:poolPreparedStatements="false"
+          p:maxPoolPreparedStatementPerConnectionSize="20"
+          p:connectionProperties="config.decrypt=true"
+          p:filters="stat,config"/>
 
     <bean id="dataSource" class="com.nicksxs.springdemo.config.DynamicDataSource">
         <property name="targetDataSources">
@@ -10431,29 +10147,211 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"}
     }
 
-    @After("pointCut()")
-    public void after() {
-				DatabaseContextHolder.clearDatabaseType();
-    }
-}

+    @After("pointCut()")
+    public void after() {
+				DatabaseContextHolder.clearDatabaseType();
+    }
+}

+
+
通过接口判断是否带有注解跟是注解的值，DatabaseType 的配置不太好，不过先忽略了，然后在切点后进行清理

+
这是我 master1 的数据，

+

+
master2 的数据

+

+
然后跑一下简单的 demo，

+
@Override
+public void run(String...args) {
+	LOGGER.info("run here");
+	System.out.println(studentService.queryOne());
+	System.out.println(studentService.queryAnother());
+
+}

+
+
看一下运行结果

+

+
其实这个方法应用场景不止可以用来迁移数据库，还能实现精细化的读写数据源分离之类的，算是做个简单记录和分享。

+]]>
+      
+        Java
+        SpringBoot
+      
+      
+        Java
+        Spring
+        SpringBoot
+        Druid
+        数据源动态切换
+      
+  
+  
+    聊一下 SpringBoot 中使用的 cglib 作为动态代理中的一个注意点
+    /2021/09/19/%E8%81%8A%E4%B8%80%E4%B8%8B-SpringBoot-%E4%B8%AD%E4%BD%BF%E7%94%A8%E7%9A%84-cglib-%E4%BD%9C%E4%B8%BA%E5%8A%A8%E6%80%81%E4%BB%A3%E7%90%86%E4%B8%AD%E7%9A%84%E4%B8%80%E4%B8%AA%E6%B3%A8%E6%84%8F%E7%82%B9/
+    这个话题是由一次组内同学分享引出来的，首先在 springboot 2.x 开始默认使用了 cglib 作为 aop 的实现，这里也稍微讲一下，在一个 1.x 的老项目里，可以看到AopAutoConfiguration 是这样的

+
@Configuration
+@ConditionalOnClass({ EnableAspectJAutoProxy.class, Aspect.class, Advice.class })
+@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
+public class AopAutoConfiguration {
+
+	@Configuration
+	@EnableAspectJAutoProxy(proxyTargetClass = false)
+	@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false", matchIfMissing = true)
+	public static class JdkDynamicAutoProxyConfiguration {
+	}
+
+	@Configuration
+	@EnableAspectJAutoProxy(proxyTargetClass = true)
+	@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true", matchIfMissing = false)
+	public static class CglibAutoProxyConfiguration {
+	}
+
+}

+
+
而在 2.x 中变成了这样

+
@Configuration(proxyBeanMethods = false)
+@ConditionalOnProperty(prefix = "spring.aop", name = "auto", havingValue = "true", matchIfMissing = true)
+public class AopAutoConfiguration {
+
+	@Configuration(proxyBeanMethods = false)
+	@ConditionalOnClass(Advice.class)
+	static class AspectJAutoProxyingConfiguration {
+
+		@Configuration(proxyBeanMethods = false)
+		@EnableAspectJAutoProxy(proxyTargetClass = false)
+		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "false")
+		static class JdkDynamicAutoProxyConfiguration {
+
+		}
+
+		@Configuration(proxyBeanMethods = false)
+		@EnableAspectJAutoProxy(proxyTargetClass = true)
+		@ConditionalOnProperty(prefix = "spring.aop", name = "proxy-target-class", havingValue = "true",
+				matchIfMissing = true)
+		static class CglibAutoProxyConfiguration {
+
+		}
+
+	}

+
+
为何会加载 AopAutoConfiguration 在前面的文章聊聊 SpringBoot 自动装配里已经介绍过，有兴趣的可以看下，可以发现 springboot 在 2.x 版本开始使用 cglib 作为默认的动态代理实现。

+
然后就是出现的问题了，代码是这样的，一个简单的基于 springboot 的带有数据库的插入，对插入代码加了事务注解，

+
@Mapper
+public interface StudentMapper {
+		// 就是插入一条数据
+    @Insert("insert into student(name, age)" + "values ('nick', '18')")
+    public Long insert();
+}
+
+@Component
+public class StudentManager {
+
+    @Resource
+    private StudentMapper studentMapper;
+    
+    public Long createStudent() {
+        return studentMapper.insert();
+    }
+}
+
+@Component
+public class StudentServiceImpl implements StudentService {
+
+    @Resource
+    private StudentManager studentManager;
+
+    // 自己引用
+    @Resource
+    private StudentServiceImpl studentService;
+
+    @Override
+    @Transactional
+    public Long createStudent() {
+        Long id = studentManager.createStudent();
+        Long id2 = studentService.createStudent2();
+        return 1L;
+    }
+
+    @Transactional
+    private Long createStudent2() {
+//        Integer t = Integer.valueOf("aaa");
+        return studentManager.createStudent();
+    }
+}

+
+
第一个公有方法 createStudent 首先调用了 manager 层的创建方法，然后再通过引入的 studentService 调用了createStudent2，我们先跑一下看看会出现啥情况，果不其然报错了，正是这个报错让我纠结了很久

+
EdR7oB

+
报了个空指针，而且是在 createStudent2 已经被调用到了，在它的内部，报的 studentManager 是 null，首先 cglib 作为动态代理它是通过继承的方式来实现的，相当于是会在调用目标对象的代理方法时调用 cglib 生成的子类，具体的代理切面逻辑在子类实现，然后在调用目标对象的目标方法，但是继承的方式对于 final 和私有方法其实是没法进行代理的，因为没法继承，所以我最开始的想法是应该通过 studentService 调用 createStudent2 的时候就报错了，也就是不会进入这个方法内部，后面才发现犯了个特别二的错误，继承的方式去调用父类的私有方法，对于 Java 来说是可以调用到的，父类的私有方法并不由子类的InstanceKlass维护，只能通过子类的InstanceKlass找到Java类对应的_super，这样间接地访问。也就是说子类其实是可以访问的，那为啥访问了会报空指针呢，这里报的是studentManager 是空的，可以往依赖注入方面去想，如果忽略依赖注入，我这个studentManager 的确是 null，那是不是就没有被依赖注入呢，但是为啥前面那个可以呢

+
这个问题着实查了很久，不废话来看代码

+
@Override
+		protected Object invokeJoinpoint() throws Throwable {
+			if (this.methodProxy != null) {
+        // 这里的 target 就是被代理的 bean
+				return this.methodProxy.invoke(this.target, this.arguments);
+			}
+			else {
+				return super.invokeJoinpoint();
+			}
+		}

+
+
+
+
这个是org.springframework.aop.framework.CglibAopProxy.CglibMethodInvocation的代码，其实它在这里不是直接调用 super 也就是父类的方法，而是通过 methodProxy 调用 target 目标对象的方法，也就是原始的 studentService bean 的方法，这样子 spring 管理的已经做好依赖注入的 bean 就能正常起作用，否则就会出现上面的问题，因为 cglib 其实是通过继承来实现，通过将调用转移到子类上加入代理逻辑，我们在简单使用的时候会直接 invokeSuper() 调用父类的方法，但是在这里 spring 的场景里需要去支持 spring 的功能逻辑，所以上面的问题就可以开始来解释了，因为 createStudent 是公共方法，cglib 可以对其进行继承代理，但是在执行逻辑的时候其实是通过调用目标对象，也就是 spring 管理的被代理的目标对象的 bean 调用的 createStudent，而对于下面的 createStudent2 方法因为是私有方法，不会走代理逻辑，也就不会有调用回目标对象的逻辑，只是通过继承关系，在子类中没有这个方法，所以会通过子类的InstanceKlass找到这个类对应的_super，然后调用父类的这个私有方法，这里要搞清楚一个点，从这个代理类直接找到其父类然后调用这个私有方法，这个类是由 cglib 生成的，不是被 spring 管理起来经过依赖注入的 bean，所以是没有 studentManager 这个依赖的，也就出现了前面的问题

+
而在前面提到的cglib通过methodProxy调用到目标对象，目标对象是在什么时候设置的呢，其实是在bean的生命周期中，org.springframework.beans.factory.config.BeanPostProcessor#postProcessAfterInitialization这个接口的在bean的初始化过程中，会调用实现了这个接口的方法，

+
@Override
+public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
+	if (bean != null) {
+		Object cacheKey = getCacheKey(bean.getClass(), beanName);
+		if (this.earlyProxyReferences.remove(cacheKey) != bean) {
+			return wrapIfNecessary(bean, beanName, cacheKey);
+		}
+	}
+	return bean;
+}

+
+
具体的逻辑在 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#wrapIfNecessary这个方法里

+
protected Object getCacheKey(Class<?> beanClass, @Nullable String beanName) {
+		if (StringUtils.hasLength(beanName)) {
+			return (FactoryBean.class.isAssignableFrom(beanClass) ?
+					BeanFactory.FACTORY_BEAN_PREFIX + beanName : beanName);
+		}
+		else {
+			return beanClass;
+		}
+	}
+
+	/**
+	 * Wrap the given bean if necessary, i.e. if it is eligible for being proxied.
+	 * @param bean the raw bean instance
+	 * @param beanName the name of the bean
+	 * @param cacheKey the cache key for metadata access
+	 * @return a proxy wrapping the bean, or the raw bean instance as-is
+	 */
+	protected Object wrapIfNecessary(Object bean, String beanName, Object cacheKey) {
+		if (StringUtils.hasLength(beanName) && this.targetSourcedBeans.contains(beanName)) {
+			return bean;
+		}
+		if (Boolean.FALSE.equals(this.advisedBeans.get(cacheKey))) {
+			return bean;
+		}
+		if (isInfrastructureClass(bean.getClass()) || shouldSkip(bean.getClass(), beanName)) {
+			this.advisedBeans.put(cacheKey, Boolean.FALSE);
+			return bean;
+		}
 
-
通过接口判断是否带有注解跟是注解的值，DatabaseType 的配置不太好，不过先忽略了，然后在切点后进行清理

-
这是我 master1 的数据，

-

-
master2 的数据

-

-
然后跑一下简单的 demo，

-
@Override
-public void run(String...args) {
-	LOGGER.info("run here");
-	System.out.println(studentService.queryOne());
-	System.out.println(studentService.queryAnother());
+		// Create proxy if we have advice.
+		Object[] specificInterceptors = getAdvicesAndAdvisorsForBean(bean.getClass(), beanName, null);
+		if (specificInterceptors != DO_NOT_PROXY) {
+			this.advisedBeans.put(cacheKey, Boolean.TRUE);
+			Object proxy = createProxy(
+					bean.getClass(), beanName, specificInterceptors, new SingletonTargetSource(bean));
+			this.proxyTypes.put(cacheKey, proxy.getClass());
+			return proxy;
+		}
 
-}

+		this.advisedBeans.put(cacheKey, Boolean.FALSE);
+		return bean;
+	}

 
-
看一下运行结果

-

-
其实这个方法应用场景不止可以用来迁移数据库，还能实现精细化的读写数据源分离之类的，算是做个简单记录和分享。

+
然后在 org.springframework.aop.framework.autoproxy.AbstractAutoProxyCreator#createProxy 中创建了代理类

 ]]>
       
         Java
@@ -10463,8 +10361,8 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"跳水
       
   
+  
+    聊聊 Dubbo 的 SPI
+    /2020/05/31/%E8%81%8A%E8%81%8A-Dubbo-%E7%9A%84-SPI/
+    SPI全称是Service Provider Interface，咋眼看跟api是不是有点相似，api是application interface，这两个其实在某些方面有类似的地方，也有蛮大的区别，比如我们基于 dubbo 的微服务，一般我们可以提供服务，然后非泛化调用的话，我们可以把 api 包提供给应用调用方，他们根据接口签名传对应参数并配置好对应的服务发现如 zk 等就可以调用我们的服务了，然后 spi 会有点类似但是是反过来的关系，相当于是一种规范，比如我约定完成这个功能需要两个有两个接口，一个是连接的，一个是断开的，其实就可以用 jdbc 的驱动举例，比较老套了，然后各个厂家去做具体的实现吧，到时候根据我接口的全限定名的文件来加载实际的实现类，然后运行的时候调用对应实现类的方法就完了

+
3sKdpg

+
看上面的图，java.sql.Driver就是 spi，对应在classpath 的 META-INF/services 目录下的这个文件，里边的内容就是具体的实现类

+
1590735097909

+
简单介绍了 Java的 SPI，再来说说 dubbo 的，dubbo 中为啥要用 SPI 呢，主要是为了框架的可扩展性和性能方面的考虑，比如协议层 dubbo 默认使用 dubbo 协议，同时也支持很多其他协议，也支持用户自己实现协议，那么跟 Java 的 SPI 会有什么区别呢，我们也来看个文件

+
bqxWMp

+
是不是看着很想，又有点不一样，在 Java 的 SPI 配置文件里每一行只有一个实现类的全限定名，在 Dubbo的 SPI配置文件中是 key=value 的形式，我们只需要对应的 key 就能加载对应的实现，

+
/**
+     * 返回指定名字的扩展。如果指定名字的扩展不存在，则抛异常 {@link IllegalStateException}.
+     *
+     * @param name
+     * @return
+     */
+	@SuppressWarnings("unchecked")
+	public T getExtension(String name) {
+		if (name == null || name.length() == 0)
+		    throw new IllegalArgumentException("Extension name == null");
+		if ("true".equals(name)) {
+		    return getDefaultExtension();
+		}
+		Holder<Object> holder = cachedInstances.get(name);
+		if (holder == null) {
+		    cachedInstances.putIfAbsent(name, new Holder<Object>());
+		    holder = cachedInstances.get(name);
+		}
+		Object instance = holder.get();
+		if (instance == null) {
+		    synchronized (holder) {
+	            instance = holder.get();
+	            if (instance == null) {
+	                instance = createExtension(name);
+	                holder.set(instance);
+	            }
+	        }
+		}
+		return (T) instance;
+	}

+
这里其实就可以看出来第二个不同点了，就是这个cachedInstances，第一个是不用像 Java 原生的 SPI 那样去遍历加载对应的服务类，只需要通过 key 去寻找，并且寻找的时候会先从缓存的对象里去取，还有就是注意下这里的 DCL(double check lock)

+
@SuppressWarnings("unchecked")
+    private T createExtension(String name) {
+        Class<?> clazz = getExtensionClasses().get(name);
+        if (clazz == null) {
+            throw findException(name);
+        }
+        try {
+            T instance = (T) EXTENSION_INSTANCES.get(clazz);
+            if (instance == null) {
+                EXTENSION_INSTANCES.putIfAbsent(clazz, (T) clazz.newInstance());
+                instance = (T) EXTENSION_INSTANCES.get(clazz);
+            }
+            injectExtension(instance);
+            Set<Class<?>> wrapperClasses = cachedWrapperClasses;
+            if (wrapperClasses != null && wrapperClasses.size() > 0) {
+                for (Class<?> wrapperClass : wrapperClasses) {
+                    instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
+                }
+            }
+            return instance;
+        } catch (Throwable t) {
+            throw new IllegalStateException("Extension instance(name: " + name + ", class: " +
+                    type + ")  could not be instantiated: " + t.getMessage(), t);
+        }
+    }

+
然后就是创建扩展了，这里如果 wrapperClasses 就会遍历生成wrapper实例，并做 setter 依赖注入，但是这里cachedWrapperClasses的来源还是有点搞不清楚，得再看下 com.alibaba.dubbo.common.extension.ExtensionLoader#loadFile的具体逻辑
又看了遍新的代码，这个函数被抽出来了

+
/**
+    * test if clazz is a wrapper class
+    * <p>
+    * which has Constructor with given class type as its only argument
+    */
+   private boolean isWrapperClass(Class<?> clazz) {
+       try {
+           clazz.getConstructor(type);
+           return true;
+       } catch (NoSuchMethodException e) {
+           return false;
+       }
+   }

+
是否是 wrapperClass 其实就看构造函数的。

+]]>
+      
+        Java
+        Dubbo
+        RPC
+        SPI
+        Dubbo
+        SPI
+      
+      
+        Java
+        Dubbo
+        RPC
+        SPI
+      
+  
   
     聊聊 Dubbo 的 SPI 续之自适应拓展
     /2020/06/06/%E8%81%8A%E8%81%8A-Dubbo-%E7%9A%84-SPI-%E7%BB%AD%E4%B9%8B%E8%87%AA%E9%80%82%E5%BA%94%E6%8B%93%E5%B1%95/
@@ -10606,136 +10601,36 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"}
 
         com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class)
-                                                                                                   .getExtension(extName);
-
-        return extension.export(arg0);
-    }
-
-    public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0,
-        com.alibaba.dubbo.common.URL arg1)
-        throws com.alibaba.dubbo.rpc.RpcException {
-        if (arg1 == null) {
-            throw new IllegalArgumentException("url == null");
-        }
-
-        com.alibaba.dubbo.common.URL url = arg1;
-      // 其实前面所说的逻辑就在这里呈现了
-        String extName = ((url.getProtocol() == null) ? "dubbo"
-                                                      : url.getProtocol());
-
-        if (extName == null) {
-            throw new IllegalStateException(
-                "Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" +
-                url.toString() + ") use keys([protocol])");
-        }
-				// 在这就是实际的通过dubbo 的 spi 去加载实际对应的扩展
-        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class)
-                                                                                                   .getExtension(extName);
-
-        return extension.refer(arg0, arg1);
-    }
-}
-

-]]>
-      
-        Java
-        Dubbo
-        RPC
-        SPI
-        Dubbo
-        SPI
-        Adaptive
-      
-      
-        Java
-        Dubbo
-        RPC
-        SPI
-        Adaptive
-        自适应拓展
-      
-  
-  
-    聊聊 Dubbo 的 SPI
-    /2020/05/31/%E8%81%8A%E8%81%8A-Dubbo-%E7%9A%84-SPI/
-    SPI全称是Service Provider Interface，咋眼看跟api是不是有点相似，api是application interface，这两个其实在某些方面有类似的地方，也有蛮大的区别，比如我们基于 dubbo 的微服务，一般我们可以提供服务，然后非泛化调用的话，我们可以把 api 包提供给应用调用方，他们根据接口签名传对应参数并配置好对应的服务发现如 zk 等就可以调用我们的服务了，然后 spi 会有点类似但是是反过来的关系，相当于是一种规范，比如我约定完成这个功能需要两个有两个接口，一个是连接的，一个是断开的，其实就可以用 jdbc 的驱动举例，比较老套了，然后各个厂家去做具体的实现吧，到时候根据我接口的全限定名的文件来加载实际的实现类，然后运行的时候调用对应实现类的方法就完了

-
3sKdpg

-
看上面的图，java.sql.Driver就是 spi，对应在classpath 的 META-INF/services 目录下的这个文件，里边的内容就是具体的实现类

-
1590735097909

-
简单介绍了 Java的 SPI，再来说说 dubbo 的，dubbo 中为啥要用 SPI 呢，主要是为了框架的可扩展性和性能方面的考虑，比如协议层 dubbo 默认使用 dubbo 协议，同时也支持很多其他协议，也支持用户自己实现协议，那么跟 Java 的 SPI 会有什么区别呢，我们也来看个文件

-
bqxWMp

-
是不是看着很想，又有点不一样，在 Java 的 SPI 配置文件里每一行只有一个实现类的全限定名，在 Dubbo的 SPI配置文件中是 key=value 的形式，我们只需要对应的 key 就能加载对应的实现，

-
/**
-     * 返回指定名字的扩展。如果指定名字的扩展不存在，则抛异常 {@link IllegalStateException}.
-     *
-     * @param name
-     * @return
-     */
-	@SuppressWarnings("unchecked")
-	public T getExtension(String name) {
-		if (name == null || name.length() == 0)
-		    throw new IllegalArgumentException("Extension name == null");
-		if ("true".equals(name)) {
-		    return getDefaultExtension();
-		}
-		Holder<Object> holder = cachedInstances.get(name);
-		if (holder == null) {
-		    cachedInstances.putIfAbsent(name, new Holder<Object>());
-		    holder = cachedInstances.get(name);
-		}
-		Object instance = holder.get();
-		if (instance == null) {
-		    synchronized (holder) {
-	            instance = holder.get();
-	            if (instance == null) {
-	                instance = createExtension(name);
-	                holder.set(instance);
-	            }
-	        }
-		}
-		return (T) instance;
-	}

-
这里其实就可以看出来第二个不同点了，就是这个cachedInstances，第一个是不用像 Java 原生的 SPI 那样去遍历加载对应的服务类，只需要通过 key 去寻找，并且寻找的时候会先从缓存的对象里去取，还有就是注意下这里的 DCL(double check lock)

-
@SuppressWarnings("unchecked")
-    private T createExtension(String name) {
-        Class<?> clazz = getExtensionClasses().get(name);
-        if (clazz == null) {
-            throw findException(name);
+                                                                                                   .getExtension(extName);
+
+        return extension.export(arg0);
+    }
+
+    public com.alibaba.dubbo.rpc.Invoker refer(java.lang.Class arg0,
+        com.alibaba.dubbo.common.URL arg1)
+        throws com.alibaba.dubbo.rpc.RpcException {
+        if (arg1 == null) {
+            throw new IllegalArgumentException("url == null");
         }
-        try {
-            T instance = (T) EXTENSION_INSTANCES.get(clazz);
-            if (instance == null) {
-                EXTENSION_INSTANCES.putIfAbsent(clazz, (T) clazz.newInstance());
-                instance = (T) EXTENSION_INSTANCES.get(clazz);
-            }
-            injectExtension(instance);
-            Set<Class<?>> wrapperClasses = cachedWrapperClasses;
-            if (wrapperClasses != null && wrapperClasses.size() > 0) {
-                for (Class<?> wrapperClass : wrapperClasses) {
-                    instance = injectExtension((T) wrapperClass.getConstructor(type).newInstance(instance));
-                }
-            }
-            return instance;
-        } catch (Throwable t) {
-            throw new IllegalStateException("Extension instance(name: " + name + ", class: " +
-                    type + ")  could not be instantiated: " + t.getMessage(), t);
+
+        com.alibaba.dubbo.common.URL url = arg1;
+      // 其实前面所说的逻辑就在这里呈现了
+        String extName = ((url.getProtocol() == null) ? "dubbo"
+                                                      : url.getProtocol());
+
+        if (extName == null) {
+            throw new IllegalStateException(
+                "Fail to get extension(com.alibaba.dubbo.rpc.Protocol) name from url(" +
+                url.toString() + ") use keys([protocol])");
         }
-    }

-
然后就是创建扩展了，这里如果 wrapperClasses 就会遍历生成wrapper实例，并做 setter 依赖注入，但是这里cachedWrapperClasses的来源还是有点搞不清楚，得再看下 com.alibaba.dubbo.common.extension.ExtensionLoader#loadFile的具体逻辑
又看了遍新的代码，这个函数被抽出来了

-
/**
-    * test if clazz is a wrapper class
-    * <p>
-    * which has Constructor with given class type as its only argument
-    */
-   private boolean isWrapperClass(Class<?> clazz) {
-       try {
-           clazz.getConstructor(type);
-           return true;
-       } catch (NoSuchMethodException e) {
-           return false;
-       }
-   }

-
是否是 wrapperClass 其实就看构造函数的。

+				// 在这就是实际的通过dubbo 的 spi 去加载实际对应的扩展
+        com.alibaba.dubbo.rpc.Protocol extension = (com.alibaba.dubbo.rpc.Protocol) ExtensionLoader.getExtensionLoader(com.alibaba.dubbo.rpc.Protocol.class)
+                                                                                                   .getExtension(extName);
+
+        return extension.refer(arg0, arg1);
+    }
+}
+

 ]]>
       
         Java
@@ -10744,12 +10639,15 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT": : Mysql 字符编码和排序规则
这个一直是属于一知半解的状态，知道 utf8 跟 utf8mb4 的区别主要是能不能支持 emoji，但是具体后面配置的排序规则是用来干嘛，或者有什么区别，应该使用哪个，所以在 stackoverflow 上找了下，有两个比较不错的解答，就搬过来并且配合机翻做了点修改

+
原文
For those people still arriving at this question in 2020 or later, there are newer options that may be better than both of these. For example, utf8mb4_0900_ai_ci.

+
All these collations are for the UTF-8 character encoding. The differences are in how text is sorted and compared.

+
_unicode_ci and _general_ci are two different sets of rules for sorting and comparing text according to the way we expect. Newer versions of MySQL introduce new sets of rules, too, such as _0900_ai_ci for equivalent rules based on Unicode 9.0 - and with no equivalent _general_ci variant. People reading this now should probably use one of these newer collations instead of either _unicode_ci or _general_ci. The description of those older collations below is provided for interest only.

+
MySQL is currently transitioning away from an older, flawed UTF-8 implementation. For now, you need to use utf8mb4 instead of utf8 for the character encoding part, to ensure you are getting the fixed version. The flawed version remains for backward compatibility, though it is being deprecated.

+
Key differences

+
utf8mb4_unicode_ci is based on the official Unicode rules for universal sorting and comparison, which sorts accurately in a wide range of languages.

+
utf8mb4_general_ci is a simplified set of sorting rules which aims to do as well as it can while taking many short-cuts designed to improve speed. It does not follow the Unicode rules and will result in undesirable sorting or comparison in some situations, such as when using particular languages or characters.

+
On modern servers, this performance boost will be all but negligible. It was devised in a time when servers had a tiny fraction of the CPU performance of today’s computers.

+
Benefits of utf8mb4_unicode_ci over utf8mb4_general_ci

+
utf8mb4_unicode_ci, which uses the Unicode rules for sorting and comparison, employs a fairly complex algorithm for correct sorting in a wide range of languages and when using a wide range of special characters. These rules need to take into account language-specific conventions; not everybody sorts their characters in what we would call ‘alphabetical order’.

+
As far as Latin (ie “European”) languages go, there is not much difference between the Unicode sorting and the simplified utf8mb4_general_cisorting in MySQL, but there are still a few differences:

+
For examples, the Unicode collation sorts “ß” like “ss”, and “Œ” like “OE” as people using those characters would normally want, whereas utf8mb4_general_cisorts them as single characters (presumably like “s” and “e” respectively).

+
Some Unicode characters are defined as ignorable, which means they shouldn’t count toward the sort order and the comparison should move on to the next character instead. utf8mb4_unicode_cihandles these properly.

+
In non-latin languages, such as Asian languages or languages with different alphabets, there may be a lot more differences between Unicode sorting and the simplified utf8mb4_general_cisorting. The suitability of utf8mb4_general_ciwill depend heavily on the language used. For some languages, it’ll be quite inadequate.

+
What should you use?

+
There is almost certainly no reason to use utf8mb4_general_cianymore, as we have left behind the point where CPU speed is low enough that the performance difference would be important. Your database will almost certainly be limited by other bottlenecks than this.

+
In the past, some people recommended to use utf8mb4_general_ciexcept when accurate sorting was going to be important enough to justify the performance cost. Today, that performance cost has all but disappeared, and developers are treating internationalization more seriously.

+
There’s an argument to be made that if speed is more important to you than accuracy, you may as well not do any sorting at all. It’s trivial to make an algorithm faster if you do not need it to be accurate. So, utf8mb4_general_ciis a compromise that’s probably not needed for speed reasons and probably also not suitable for accuracy reasons.

+
One other thing I’ll add is that even if you know your application only supports the English language, it may still need to deal with people’s names, which can often contain characters used in other languages in which it is just as important to sort correctly. Using the Unicode rules for everything helps add peace of mind that the very smart Unicode people have worked very hard to make sorting work properly.

+
What the parts mean

+
Firstly, ci is for case-insensitive sorting and comparison. This means it’s suitable for textual data, and case is not important. The other types of collation are cs (case-sensitive) for textual data where case is important, and bin, for where the encoding needs to match, bit for bit, which is suitable for fields which are really encoded binary data (including, for example, Base64). Case-sensitive sorting leads to some weird results and case-sensitive comparison can result in duplicate values differing only in letter case, so case-sensitive collations are falling out of favor for textual data - if case is significant to you, then otherwise ignorable punctuation and so on is probably also significant, and a binary collation might be more appropriate.

+
Next, unicode or general refers to the specific sorting and comparison rules - in particular, the way text is normalized or compared. There are many different sets of rules for the utf8mb4 character encoding, with unicode and general being two that attempt to work well in all possible languages rather than one specific one. The differences between these two sets of rules are the subject of this answer. Note that unicode uses rules from Unicode 4.0. Recent versions of MySQL add the rulesets unicode_520 using rules from Unicode 5.2, and 0900 (dropping the “unicode_” part) using rules from Unicode 9.0.

+
And lastly, utf8mb4 is of course the character encoding used internally. In this answer I’m talking only about Unicode based encodings.

+
翻译
对于那些在 2020 年或之后仍会遇到这个问题的人，有可能比这两个更好的新选项。例如，utf8mb4_0900_ai_ci。

+
所有这些排序规则都用于 UTF-8 字符编码。不同之处在于文本的排序和比较方式。

+
_unicode_ci和 _general_ci是两组不同的规则，用于按照我们期望的方式对文本进行排序和比较。较新版本的 MySQL 也引入了新的规则集，例如 _0900_ai_ci用于基于 Unicode 9.0 的等效规则 - 并且没有等效的 _general_ci变体。现在阅读本文的人可能应该使用这些较新的排序规则之一，而不是 _unicode_ci或 _general_ci。下面对那些较旧的排序规则的描述仅供参考。

+
MySQL 目前正在从旧的、有缺陷的 UTF-8 实现过渡。现在，您需要使用 utf8mb4 而不是 utf8作为字符编码部分，以确保您获得的是固定版本。有缺陷的版本仍然是为了向后兼容，尽管它已被弃用。

+
主要区别

+
utf8mb4_unicode_ci基于官方 Unicode 规则进行通用排序和比较，可在多种语言中准确排序。

+
utf8mb4_general_ci是一组简化的排序规则，旨在尽其所能，同时采用许多旨在提高速度的捷径。它不遵循 Unicode 规则，并且在某些情况下会导致不希望的排序或比较，例如在使用特定语言或字符时。

+
在现代服务器上，这种性能提升几乎可以忽略不计。它是在服务器的 CPU 性能只有当今计算机的一小部分时设计的。

+
utf8mb4_unicode_ci 相对于 utf8mb4_general_ci的优势

+
utf8mb4_unicode_ci使用 Unicode 规则进行排序和比较，采用相当复杂的算法在多种语言中以及在使用多种特殊字符时进行正确排序。这些规则需要考虑特定语言的约定；不是每个人都按照我们所说的“字母顺序”对他们的字符进行排序。

+
就拉丁语（即“欧洲”）语言而言，Unicode 排序和 MySQL 中简化的 utf8mb4_general_ci排序没有太大区别，但仍有一些区别：

+
例如，Unicode 排序规则将“ß”排序为“ss”，将“Œ”排序为“OE”，因为使用这些字符的人通常需要这些字符，而 utf8mb4_general_ci将它们排序为单个字符（大概分别像“s”和“e” ）。

+
一些 Unicode 字符被定义为可忽略，这意味着它们不应该计入排序顺序，并且比较应该转到下一个字符。 utf8mb4_unicode_ci正确处理这些。

+
在非拉丁语言中，例如亚洲语言或具有不同字母的语言，Unicode 排序和简化的 utf8mb4_general_ci排序之间可能存在更多差异。 utf8mb4_general_ci的适用性在很大程度上取决于所使用的语言。对于某些语言，这将是非常不充分的。

+
你应该用什么？

+
几乎可以肯定没有理由再使用 utf8mb4_general_ci，因为我们已经将 CPU 速度低到会严重影响性能表现的时代远抛在脑后了。您的数据库几乎肯定会受到除此之外的其他瓶颈的限制。

+
过去，有些人建议使用 utf8mb4_general_ci，除非准确排序足够重要以证明性能成本是合理的。如今，这种性能成本几乎消失了，开发人员正在更加认真地对待国际化。

+
有一个论点是，如果速度对您来说比准确性更重要，那么您可能根本不进行任何排序。如果您不需要准确的算法，那么使算法更快是微不足道的。因此，utf8mb4_general_ci是一种折衷方案，出于速度原因可能不需要，也可能出于准确性原因也不适合。

+
我要补充的另一件事是，即使您知道您的应用程序仅支持英语，它可能仍需要处理人名，这些人名通常包含其他语言中使用的字符，在这些语言中正确排序同样重要.对所有事情都使用 Unicode 规则有助于让您更加安心，因为非常聪明的 Unicode 人员已经非常努力地工作以使排序正常工作。

+
其余各个部分是什么意思

+
首先， ci 用于不区分大小写的排序和比较。这意味着它适用于文本数据，大小写并不重要。其他类型的排序规则是 cs（区分大小写），用于区分大小写的文本数据，以及 bin，用于编码需要匹配的地方，逐位匹配，适用于真正编码二进制数据的字段（包括，用于例如，Base64）。区分大小写的排序会导致一些奇怪的结果，区分大小写的比较可能会导致重复值仅在字母大小写上有所不同，因此区分大小写的排序规则对文本数据不受欢迎 - 如果大小写对您很重要，那么标点符号就可以忽略等等可能也很重要，二进制排序规则可能更合适。

+
接下来，unicode 或general 指的是具体的排序和比较规则——特别是文本被规范化或比较的方式。 utf8mb4 字符编码有许多不同的规则集，其中 unicode 和 general 是两种，它们试图在所有可能的语言中都很好地工作，而不是在一种特定的语言中。这两组规则之间的差异是此答案的主题。请注意，unicode 使用 Unicode 4.0 中的规则。 MySQL 的最新版本使用 Unicode 5.2 的规则添加规则集 unicode_520，使用 Unicode 9.0 的规则添加 0900（删除“unicode_”部分）。

+
最后，utf8mb4 当然是内部使用的字符编码。在这个答案中，我只谈论基于 Unicode 的编码。

+
utf8 和 utf8mb4 编码有什么区别
原文
UTF-8is a variable-length encoding. In the case of UTF-8, this means that storing one code point requires one to four bytes. However, MySQL’s encoding called “utf8” (alias of “utf8mb3”) only stores a maximum of three bytes per code point.

+
So the character set “utf8”/“utf8mb3” cannot store all Unicode code points: it only supports the range 0x000 to 0xFFFF, which is called the “Basic Multilingual Plane“. See also Comparison of Unicode encodings.

+
This is what (a previous version of the same page at)the MySQL documentationhas to say about it:

+

+
The character set named utf8[/utf8mb3] uses a maximum of three bytes per character and contains only BMP characters. As of MySQL 5.5.3, the utf8mb4 character set uses a maximum of four bytes per character supports supplemental characters:

+
    
+
  • For a BMP character, utf8[/utf8mb3] and utf8mb4 have identical storage characteristics: same code values, same encoding, same length.
    • 
+
  • For a supplementary character, utf8[/utf8mb3] cannot store the character at all, while utf8mb4 requires four bytes to store it. Since utf8[/utf8mb3] cannot store the character at all, you do not have any supplementary characters in utf8[/utf8mb3] columns and you need not worry about converting characters or losing data when upgrading utf8[/utf8mb3] data from older versions of MySQL.
    • 
+

+

+
So if you want your column to support storing characters lying outside the BMP (and you usually want to), such as emoji, use “utf8mb4”. See also What are the most common non-BMP Unicode characters in actual use?.

+
译文
UTF-8 是一种可变长度编码。对于 UTF-8，这意味着存储一个代码点需要一到四个字节。但是，MySQL 的编码称为“utf8”（“utf8mb3”的别名）每个代码点最多只能存储三个字节。

+
所以字符集“utf8”/“utf8mb3”不能存储所有的Unicode码位：它只支持0x000到0xFFFF的范围，被称为“基本多语言平面”。另请参阅 Unicode 编码比较。

+
这就是（同一页面的先前版本）MySQL 文档 不得不说的：

+

+
名为 utf8[/utf8mb3] 的字符集每个字符最多使用三个字节，并且仅包含 BMP 字符。从 MySQL 5.5.3 开始，utf8mb4 字符集每个字符最多使用四个字节，支持补充字符：

+
    
+
  • 对于 BMP 字符，utf8[/utf8mb3] 和 utf8mb4 具有相同的存储特性：相同的代码值、相同的编码、相同的长度。
    • 
+
  • 对于补充字符，utf8[/utf8mb3] 根本无法存储该字符，而 utf8mb4 需要四个字节来存储它。由于 utf8[/utf8mb3] 根本无法存储字符，因此您在 utf8[/utf8mb3] 列中没有任何补充字符，您不必担心从旧版本升级 utf8[/utf8mb3] 数据时转换字符或丢失数据mysql。
    • 
+

+

+
因此，如果您希望您的列支持存储位于 BMP 之外的字符（并且您通常希望这样做），例如 emoji，请使用“utf8mb4”。另请参阅

+
实际使用中最常见的非 BMP Unicode 字符是什么？ 。

+]]>
+      
+        Mysql
+      
+      
+        mysql
+        字符集
+        编码
+        utf8
+        utf8mb4
+        utf8mb4_0900_ai_ci
+        utf8mb4_unicode_ci
+        utf8mb4_general_ci
+      
+  
   
     聊聊 RocketMQ 的 Broker 源码
     /2020/07/19/%E8%81%8A%E8%81%8A-RocketMQ-%E7%9A%84-Broker-%E6%BA%90%E7%A0%81/
@@ -12688,115 +12674,39 @@ result = result 调用CommitLog.start方法，启动CommitLog对象中的FlushCommitLogService线程服务，若是同步刷盘（SYNC_FLUSH）则是启动GroupCommitService线程服务；若是异步刷盘（ASYNC_FLUSH）则是启动FlushRealTimeService线程服务；
 
  • 启动StoreStatsService线程服务；
    • 
 
  • 启动定时清理任务
    • 
-
-
    然后是启动ClientHousekeepingService的 netty 服务端和客户端，然后是启动fileWatchService证书服务，接着启动BrokerOuterAPI中的NettyRemotingClient，即建立与NameServer的链接，用于自身Broker与其他模块的RPC功能调用；包括获取NameServer的地址、注册Broker、注销Broker、获取Topic配置、获取消息进度信息、获取订阅关系等RPC功能，然后是PullRequestHoldService服务线程，这个就是实现长轮询的，然后启动管家ClientHousekeepingService服务，负责扫描不活跃的生产者，消费者和 filter，启动FilterServerManager 过滤器服务管理，然后启动定时任务调用org.apache.rocketmq.broker.BrokerController#registerBrokerAll向所有 nameserver 注册 broker，最后是按需开启org.apache.rocketmq.store.stats.BrokerStatsManager和org.apache.rocketmq.broker.latency.BrokerFastFailure，基本上启动过程就完成了
    
-]]>
-      
-        MQ
-        RocketMQ
-        消息队列
-        RocketMQ
-        中间件
-        RocketMQ
-      
-      
-        MQ
-        消息队列
-        RocketMQ
-        削峰填谷
-        中间件
-        源码解析
-        Broker
-      
-      
-  
-    聊聊 Sharding-Jdbc 分库分表下的分页方案
-    /2022/01/09/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E5%88%86%E5%BA%93%E5%88%86%E8%A1%A8%E4%B8%8B%E7%9A%84%E5%88%86%E9%A1%B5%E6%96%B9%E6%A1%88/
-    前面在聊 Sharding-Jdbc 的时候看到了一篇文章，关于一个分页的查询，一直比较直接的想法就是分库分表下的分页是非常不合理的，一般我们的实操方案都是分表加上 ES 搜索做分页，或者通过合表读写分离的方案，因为对于 sharding-jdbc 如果没有带分表键，查询基本都是只能在所有分表都执行一遍，然后再加上分页，基本上是分页越大后续的查询越耗资源，但是仔细的去想这个细节还是这次，就简单说说
    首先就是我的分表结构
    
-
    CREATE TABLE `student_time_0` (
-  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
-  `user_id` int(11) NOT NULL,
-  `name` varchar(200) COLLATE utf8_bin DEFAULT NULL,
-  `age` tinyint(3) unsigned DEFAULT NULL,
-  `create_time` bigint(20) DEFAULT NULL,
-  PRIMARY KEY (`id`)
-) ENGINE=InnoDB AUTO_INCREMENT=674 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
    
-
    有这样的三个表，student_time_0, student_time_1, student_time_2, 以 user_id 作为分表键，根据表数量取模作为分表依据
    这里先构造点数据，
    
-
    insert into student_time (`name`, `user_id`, `age`, `create_time`) values (?, ?, ?, ?)
    
-
    主要是为了保证 create_time 唯一比较好说明问题，
    
-
    int i = 0;
-try (
-        Connection conn = dataSource.getConnection();
-        PreparedStatement ps = conn.prepareStatement(insertSql)) {
-    do {
-        ps.setString(1, localName + new Random().nextInt(100));
-        ps.setLong(2, 10086L + (new Random().nextInt(100)));
-        ps.setInt(3, 18);
-        ps.setLong(4, new Date().getTime());
-
-
-        int result = ps.executeUpdate();
-        LOGGER.info("current execute result: {}", result);
-        Thread.sleep(new Random().nextInt(100));
-        i++;
-    } while (i <= 2000);
    
-
    三个表的数据分别是 673，678，650，说明符合预期了，各个表数据不一样，接下来比如我们想要做一个这样的分页查询
    
-
    select * from student_time ORDER BY create_time ASC limit 1000, 5;
    
-
    student_time 对于我们使用的 sharding-jdbc 来说当然是逻辑表，首先从一无所知去想这个查询如果我们自己来处理应该是怎么做，
    首先是不是可以每个表都从 333 开始取 5 条数据，类似于下面的查询，然后进行 15 条的合并重排序获取前面的 5 条
    
-
    select * from student_time_0 ORDER BY create_time ASC limit 333, 5;
-select * from student_time_1 ORDER BY create_time ASC limit 333, 5;
-select * from student_time_2 ORDER BY create_time ASC limit 333, 5;
    
-
    忽略前面 limit 差的 1，这个结果除非三个表的分布是绝对的均匀，否则结果肯定会出现一定的偏差，以为每个表的 333 这个位置对于其他表来说都不一定是一样的，这样对于最后整体的结果，就会出现偏差
    因为一直在纠结怎么让这个更直观的表现出来，所以尝试画了个图

    黑色的框代表我从每个表里按排序从 334 到 338 的 5 条数据， 他们在每个表里都是代表了各自正确的排序值，但是对于我们想要的其实是合表后的 1001，1005 这五条，然后我们假设总的排序值位于前 1000 的分布是第 0 个表是 320 条，第 1 个表是 340 条，第 2 个表是 340 条，那么可以明显地看出来我这么查的结果简单合并肯定是不对的。
    那么 sharding-jdbc 是如何保证这个结果的呢，其实就是我在每个表里都查分页偏移量和分页大小那么多的数据，在我这个例子里就是对于 0，1，2 三个分表每个都查 1005 条数据，即使我的数据不平衡到最极端的情况，前 1005 条数据都出在某个分表中，也可以正确获得最后的结果，但是明显的问题就是大分页，数据较多，就会导致非常大的问题，即使如 sharding-jdbc 对于合并排序的优化做得比较好，也还是需要传输那么大量的数据，并且查询也耗时，那么有没有解决方案呢，应该说有两个，或者说主要是想讲后者
    第一个办法是像这种查询，如果业务上不需要进行跳页，而是只给下一页，那么我们就能把前一次的最大偏移量的 create_time 记录下来，下一页就可以拿着这个偏移量进行查询，这个比较简单易懂，就不多说了
    第二个办法是看的58 沈剑的一篇文章，尝试理解讲述一下，
    这个办法的第一步跟前面那个错误的方法或者说不准确的方法一样，先是将分页偏移量平均后在三个表里进行查询
    
-
    t0
-334 10158 nick95  18  1641548941767
-335 10098 nick11  18  1641548941879
-336 10167 nick51  18  1641548942089
-337 10167 nick3 18  1641548942119
-338 10170 nick57  18  1641548942169
-
-
-t1
-334 10105 nick98  18  1641548939071   最小
-335 10174 nick94  18  1641548939377
-336 10129 nick85  18  1641548939442
-337 10141 nick84  18  1641548939480
-338 10096 nick74  18  1641548939668
-
-t2
-334 10184 nick11  18  1641548945075
-335 10109 nick93  18  1641548945382
-336 10181 nick41  18  1641548945583
-337 10130 nick80  18  1641548945993
-338 10184 nick19  18  1641548946294  最大
    
-
    然后要做什么呢，其实目标比较明白，因为前面那种方法其实就是我知道了前一页的偏移量，所以可以直接当做条件来进行查询，那这里我也想着拿到这个条件，所以我将第一遍查出来的最小的 create_time 和最大的 create_time 找出来，然后再去三个表里查询，其实主要是最小值，因为我拿着最小值去查以后我就能知道这个最小值在每个表里处在什么位置，
    
-
    t0
-322 10161 nick81  18  1641548939284
-323 10113 nick16  18  1641548939393
-324 10110 nick56  18  1641548939577
-325 10116 nick69  18  1641548939588
-326 10173 nick51  18  1641548939646
-
-t1
-334 10105 nick98  18  1641548939071
-335 10174 nick94  18  1641548939377
-336 10129 nick85  18  1641548939442
-337 10141 nick84  18  1641548939480
-338 10096 nick74  18  1641548939668
-
-t2
-297 10136 nick28  18  1641548939161
-298 10142 nick68  18  1641548939177
-299 10124 nick41  18  1641548939237
-300 10148 nick87  18  1641548939510
-301 10169 nick23  18  1641548939715
    
-
    我只贴了前五条数据，为了方便知道偏移量，每个分表都使用了自增主键，我们可以看到前一次查询的最小值分别在其他两个表里的位置分别是 322-1 和 297-1，那么对于总体来说这个时间应该是在 322 - 1 + 333 + 297 - 1 = 951，那这样子我只要对后面的数据最多每个表查 1000 - 951 + 5 = 54 条数据再进行合并排序就可以获得最终正确的结果。
    这个就是传说中的二次查询法。
    
+
+
    然后是启动ClientHousekeepingService的 netty 服务端和客户端，然后是启动fileWatchService证书服务，接着启动BrokerOuterAPI中的NettyRemotingClient，即建立与NameServer的链接，用于自身Broker与其他模块的RPC功能调用；包括获取NameServer的地址、注册Broker、注销Broker、获取Topic配置、获取消息进度信息、获取订阅关系等RPC功能，然后是PullRequestHoldService服务线程，这个就是实现长轮询的，然后启动管家ClientHousekeepingService服务，负责扫描不活跃的生产者，消费者和 filter，启动FilterServerManager 过滤器服务管理，然后启动定时任务调用org.apache.rocketmq.broker.BrokerController#registerBrokerAll向所有 nameserver 注册 broker，最后是按需开启org.apache.rocketmq.store.stats.BrokerStatsManager和org.apache.rocketmq.broker.latency.BrokerFastFailure，基本上启动过程就完成了
    
 ]]>    
       
-        Java
+        MQ
+        RocketMQ
+        消息队列
+        RocketMQ
+        中间件
+        RocketMQ
       
       
-        Java
-        Sharding-Jdbc
+        MQ
+        消息队列
+        RocketMQ
+        削峰填谷
+        中间件
+        源码解析
+        Broker
+      
+      
+  
+    给小电驴上牌
+    /2022/03/20/%E7%BB%99%E5%B0%8F%E7%94%B5%E9%A9%B4%E4%B8%8A%E7%89%8C/
+    三八节活动的时候下决心买了个小电驴，主要是上下班路上现在通勤条件越来越恶劣了，之前都是觉得坐公交就行了，实际路程就比较短，但是现在或者说大概是年前那两个月差不多就开始了，基本是堵一路，个人感觉是天目山路那边在修地铁，而且蚂蚁的几个空间都在那，上班的时间点都差不多，前一个修地铁感觉挺久了，机动车保有量也越来越多，总体是古墩路就越来越堵，还有个原因就是早上上班的点共享单车都被骑走了，有时候整整走一路都没一辆，有时候孤零零地有一辆基本都是破的；走路其实也是一种选择，但是因为要赶着上班，走得太慢就要很久，可能要 45 分钟这样，走得比较快就一身汗挺难受的。所以考虑自行车和电动车，这里还有一点就是不管是乘公交还是骑共享单车，其实都要从楼下走出去蛮远，公司回来也是，也就是这种通勤方式在准备阶段就花了比较多时间，比如总的从下班到到家的时间是半小时，可能在骑共享单车和公交车上的时间都不到十分钟，就比较难受。觉得这种比例太浪费时间，如果能有这种比较点对点的方式，估计能省时省力不少，前面说的骑共享单车的方式其实在之前是比较可行的，但是后来越来越少车，基本都是每周的前几天，周一到周三都是没有车，走路到公司再冷的天都是走出一身的汗，下雨天就更难受，本来下雨天应该是优先选择坐公交，但是一般下雨天堵车会更严重，而且车子到我上车的那个站，下雨天就挤得不行，总体说下来感觉事情都不打，但是几年下来，还是会挺不爽的。
    
+
    电驴看的比较草率，主要是考虑续航，然后锂电池外加 48v 和 24AH，这样一般来讲还是价格比较高的，只是原来没预料到这个限速，以为现在的车子都比较快，但是现在的新国标车子都是 25km/h 的限速，然后 15km/h 都是会要提醒，虽然说有一些特殊的解除限速的方法，但是解了也就 35km/h ，差距不是特别大，而且现在的车子都是比较小，也不太能载东西，特别是上下班路程也不远的情况下，其实不是那么需要速度，就像我朋友说的，可能骑车的时间还不如等红绿灯多，所以就还好，也不打算解除限速，只是品牌上也仔细看，后来选了绿源，目前大部分还是雅迪，爱玛，台羚，绿源，小牛等，路上看的话还是雅迪比较多，不过价格也比较贵一点，还有就是小牛了，是比较新兴的品牌，手机 App 什么的做得比较好，而且也比较贵，最后以相对比较便宜的价格买了个锂电 48V24AH 的小车子，后来发现还是有点不方便的点就是没有比较大的筐，也不好装，这样就是下雨天雨衣什么的比较不方便放。
    
+
    聊回来主题上牌这个事情，这个事情也是颇费心力，提车的时候店里的让我跟他早上一起去，但是因为不确定时间，也比较远就没跟着去，因为我是线上买的，线下自提，线下的店可能没啥利润可以拿，就不肯帮忙代上牌，朋友说在线下店里买是可以代上的，自己上牌过程也比较曲折，一开始是头盔没到，然后是等开发票，主要的东西就是需要骑着车子去车管所，不能只自己去，然后需要预约，附近比较近的都是提前一周就预约完了号了，要提前在支付宝上进行预约，比较空的就是店里推荐的景区大队，但是随之而来就是比较蛋疼的，这个景区大队太远了，看下骑车距离有十几公里，所以就有点拖延症，但是总归要上的，不然一直不能开是白买了，上牌的材料主要是车辆合格证，发票，然后车子上的浙品码，在车架上和电池上，然后车架号什么的都要跟合格证上完全对应，整体车子要跟合格证上一毛一样，如果有额外的反光镜，后面副座都需要拆掉，脚踏板要装上，到了那其实还比较顺利，就是十几公里外加那天比较冷，吹得头疼。
    
+]]>    
+      
+        生活
+      
+      
+        生活
       
       
   
@@ -12895,35 +12805,6 @@ t2
         }
     }
    
 
    看下查询结果
    
-]]>
-      
-        Java
-      
-      
-        Java
-        Sharding-Jdbc
-      
-  
-  
-    聊聊 Sharding-Jdbc 的简单原理初篇
-    /2021/12/26/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E7%9A%84%E7%AE%80%E5%8D%95%E5%8E%9F%E7%90%86%E5%88%9D%E7%AF%87/
-    在上一篇 sharding-jdbc 的介绍中其实碰到过一个问题，这里也引出了一个比较有意思的话题
    就是我在执行 query 的时候犯过一个比较难发现的错误，
    
-
    ResultSet resultSet = ps.executeQuery(sql);
    
-
    实际上应该是
    
-
    ResultSet resultSet = ps.executeQuery();
    
-
    而这里的差别就是，是否传 sql 这个参数，首先我们要知道这个 ps 是什么，它也是个接口java.sql.PreparedStatement,而真正的实现类是org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement,我们来看下继承关系

    这里可以看到继承关系里有org.apache.shardingsphere.driver.jdbc.unsupported.AbstractUnsupportedOperationPreparedStatement
    那么在我上面的写错的代码里
    
-
    @Override
-public final ResultSet executeQuery(final String sql) throws SQLException {
-    throw new SQLFeatureNotSupportedException("executeQuery with SQL for PreparedStatement");
-}
    
-
    这个报错一开始让我有点懵，后来点进去了发现是这么个异常，但是我其实一开始是用的更新语句，以为更新不支持，因为平时使用没有深究过，以为是不是需要使用 Mybatis 才可以执行更新，但是理论上也不应该，再往上看原来这些异常是由 sharding-jdbc 包装的，也就是在上面说的AbstractUnsupportedOperationPreparedStatement，这其实也是一种设计思想，本身 jdbc 提供了一系列接口，由各家去支持，包括 mysql，sql server，oracle 等，而正因为这个设计，所以 sharding-jdbc 也可以在此基础上进行设计，我们可以总体地看下 sharding-jdbc 的实现基础

    看了前面ShardingSpherePreparedStatement的继承关系，应该也能猜到这里的几个类都是实现了 jdbc 的基础接口，

    在前一篇的 demo 中的
    
-
    Connection conn = dataSource.getConnection();
    
-
    其实就获得了org.apache.shardingsphere.driver.jdbc.core.connection.ShardingSphereConnection#ShardingSphereConnection
    然后获得java.sql.PreparedStatement
    
-
    PreparedStatement ps = conn.prepareStatement(sql)
    
-
    就是获取了org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement
    然后就是执行
    
-
    ResultSet resultSet = ps.executeQuery();
    
-
    然后获得结果
    org.apache.shardingsphere.driver.jdbc.core.resultset.ShardingSphereResultSet
    
-
    其实像 mybatis 也是基于这样去实现的
    
 ]]>    
       
         Java
@@ -13670,6 +13551,125 @@ $
         AutoConfiguration
       
       
+  
+    聊聊 Sharding-Jdbc 的简单原理初篇
+    /2021/12/26/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E7%9A%84%E7%AE%80%E5%8D%95%E5%8E%9F%E7%90%86%E5%88%9D%E7%AF%87/
+    在上一篇 sharding-jdbc 的介绍中其实碰到过一个问题，这里也引出了一个比较有意思的话题
    就是我在执行 query 的时候犯过一个比较难发现的错误，
    
+
    ResultSet resultSet = ps.executeQuery(sql);
    
+
    实际上应该是
    
+
    ResultSet resultSet = ps.executeQuery();
    
+
    而这里的差别就是，是否传 sql 这个参数，首先我们要知道这个 ps 是什么，它也是个接口java.sql.PreparedStatement,而真正的实现类是org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement,我们来看下继承关系

    这里可以看到继承关系里有org.apache.shardingsphere.driver.jdbc.unsupported.AbstractUnsupportedOperationPreparedStatement
    那么在我上面的写错的代码里
    
+
    @Override
+public final ResultSet executeQuery(final String sql) throws SQLException {
+    throw new SQLFeatureNotSupportedException("executeQuery with SQL for PreparedStatement");
+}
    
+
    这个报错一开始让我有点懵，后来点进去了发现是这么个异常，但是我其实一开始是用的更新语句，以为更新不支持，因为平时使用没有深究过，以为是不是需要使用 Mybatis 才可以执行更新，但是理论上也不应该，再往上看原来这些异常是由 sharding-jdbc 包装的，也就是在上面说的AbstractUnsupportedOperationPreparedStatement，这其实也是一种设计思想，本身 jdbc 提供了一系列接口，由各家去支持，包括 mysql，sql server，oracle 等，而正因为这个设计，所以 sharding-jdbc 也可以在此基础上进行设计，我们可以总体地看下 sharding-jdbc 的实现基础

    看了前面ShardingSpherePreparedStatement的继承关系，应该也能猜到这里的几个类都是实现了 jdbc 的基础接口，

    在前一篇的 demo 中的
    
+
    Connection conn = dataSource.getConnection();
    
+
    其实就获得了org.apache.shardingsphere.driver.jdbc.core.connection.ShardingSphereConnection#ShardingSphereConnection
    然后获得java.sql.PreparedStatement
    
+
    PreparedStatement ps = conn.prepareStatement(sql)
    
+
    就是获取了org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement
    然后就是执行
    
+
    ResultSet resultSet = ps.executeQuery();
    
+
    然后获得结果
    org.apache.shardingsphere.driver.jdbc.core.resultset.ShardingSphereResultSet
    
+
    其实像 mybatis 也是基于这样去实现的
    
+]]>    
+      
+        Java
+      
+      
+        Java
+        Sharding-Jdbc
+      
+      
+  
+    聊聊 Sharding-Jdbc 分库分表下的分页方案
+    /2022/01/09/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E5%88%86%E5%BA%93%E5%88%86%E8%A1%A8%E4%B8%8B%E7%9A%84%E5%88%86%E9%A1%B5%E6%96%B9%E6%A1%88/
+    前面在聊 Sharding-Jdbc 的时候看到了一篇文章，关于一个分页的查询，一直比较直接的想法就是分库分表下的分页是非常不合理的，一般我们的实操方案都是分表加上 ES 搜索做分页，或者通过合表读写分离的方案，因为对于 sharding-jdbc 如果没有带分表键，查询基本都是只能在所有分表都执行一遍，然后再加上分页，基本上是分页越大后续的查询越耗资源，但是仔细的去想这个细节还是这次，就简单说说
    首先就是我的分表结构
    
+
    CREATE TABLE `student_time_0` (
+  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
+  `user_id` int(11) NOT NULL,
+  `name` varchar(200) COLLATE utf8_bin DEFAULT NULL,
+  `age` tinyint(3) unsigned DEFAULT NULL,
+  `create_time` bigint(20) DEFAULT NULL,
+  PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=674 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
    
+
    有这样的三个表，student_time_0, student_time_1, student_time_2, 以 user_id 作为分表键，根据表数量取模作为分表依据
    这里先构造点数据，
    
+
    insert into student_time (`name`, `user_id`, `age`, `create_time`) values (?, ?, ?, ?)
    
+
    主要是为了保证 create_time 唯一比较好说明问题，
    
+
    int i = 0;
+try (
+        Connection conn = dataSource.getConnection();
+        PreparedStatement ps = conn.prepareStatement(insertSql)) {
+    do {
+        ps.setString(1, localName + new Random().nextInt(100));
+        ps.setLong(2, 10086L + (new Random().nextInt(100)));
+        ps.setInt(3, 18);
+        ps.setLong(4, new Date().getTime());
+
+
+        int result = ps.executeUpdate();
+        LOGGER.info("current execute result: {}", result);
+        Thread.sleep(new Random().nextInt(100));
+        i++;
+    } while (i <= 2000);
    
+
    三个表的数据分别是 673，678，650，说明符合预期了，各个表数据不一样，接下来比如我们想要做一个这样的分页查询
    
+
    select * from student_time ORDER BY create_time ASC limit 1000, 5;
    
+
    student_time 对于我们使用的 sharding-jdbc 来说当然是逻辑表，首先从一无所知去想这个查询如果我们自己来处理应该是怎么做，
    首先是不是可以每个表都从 333 开始取 5 条数据，类似于下面的查询，然后进行 15 条的合并重排序获取前面的 5 条
    
+
    select * from student_time_0 ORDER BY create_time ASC limit 333, 5;
+select * from student_time_1 ORDER BY create_time ASC limit 333, 5;
+select * from student_time_2 ORDER BY create_time ASC limit 333, 5;
    
+
    忽略前面 limit 差的 1，这个结果除非三个表的分布是绝对的均匀，否则结果肯定会出现一定的偏差，以为每个表的 333 这个位置对于其他表来说都不一定是一样的，这样对于最后整体的结果，就会出现偏差
    因为一直在纠结怎么让这个更直观的表现出来，所以尝试画了个图

    黑色的框代表我从每个表里按排序从 334 到 338 的 5 条数据， 他们在每个表里都是代表了各自正确的排序值，但是对于我们想要的其实是合表后的 1001，1005 这五条，然后我们假设总的排序值位于前 1000 的分布是第 0 个表是 320 条，第 1 个表是 340 条，第 2 个表是 340 条，那么可以明显地看出来我这么查的结果简单合并肯定是不对的。
    那么 sharding-jdbc 是如何保证这个结果的呢，其实就是我在每个表里都查分页偏移量和分页大小那么多的数据，在我这个例子里就是对于 0，1，2 三个分表每个都查 1005 条数据，即使我的数据不平衡到最极端的情况，前 1005 条数据都出在某个分表中，也可以正确获得最后的结果，但是明显的问题就是大分页，数据较多，就会导致非常大的问题，即使如 sharding-jdbc 对于合并排序的优化做得比较好，也还是需要传输那么大量的数据，并且查询也耗时，那么有没有解决方案呢，应该说有两个，或者说主要是想讲后者
    第一个办法是像这种查询，如果业务上不需要进行跳页，而是只给下一页，那么我们就能把前一次的最大偏移量的 create_time 记录下来，下一页就可以拿着这个偏移量进行查询，这个比较简单易懂，就不多说了
    第二个办法是看的58 沈剑的一篇文章，尝试理解讲述一下，
    这个办法的第一步跟前面那个错误的方法或者说不准确的方法一样，先是将分页偏移量平均后在三个表里进行查询
    
+
    t0
+334 10158 nick95  18  1641548941767
+335 10098 nick11  18  1641548941879
+336 10167 nick51  18  1641548942089
+337 10167 nick3 18  1641548942119
+338 10170 nick57  18  1641548942169
+
+
+t1
+334 10105 nick98  18  1641548939071   最小
+335 10174 nick94  18  1641548939377
+336 10129 nick85  18  1641548939442
+337 10141 nick84  18  1641548939480
+338 10096 nick74  18  1641548939668
+
+t2
+334 10184 nick11  18  1641548945075
+335 10109 nick93  18  1641548945382
+336 10181 nick41  18  1641548945583
+337 10130 nick80  18  1641548945993
+338 10184 nick19  18  1641548946294  最大
    
+
    然后要做什么呢，其实目标比较明白，因为前面那种方法其实就是我知道了前一页的偏移量，所以可以直接当做条件来进行查询，那这里我也想着拿到这个条件，所以我将第一遍查出来的最小的 create_time 和最大的 create_time 找出来，然后再去三个表里查询，其实主要是最小值，因为我拿着最小值去查以后我就能知道这个最小值在每个表里处在什么位置，
    
+
    t0
+322 10161 nick81  18  1641548939284
+323 10113 nick16  18  1641548939393
+324 10110 nick56  18  1641548939577
+325 10116 nick69  18  1641548939588
+326 10173 nick51  18  1641548939646
+
+t1
+334 10105 nick98  18  1641548939071
+335 10174 nick94  18  1641548939377
+336 10129 nick85  18  1641548939442
+337 10141 nick84  18  1641548939480
+338 10096 nick74  18  1641548939668
+
+t2
+297 10136 nick28  18  1641548939161
+298 10142 nick68  18  1641548939177
+299 10124 nick41  18  1641548939237
+300 10148 nick87  18  1641548939510
+301 10169 nick23  18  1641548939715
    
+
    我只贴了前五条数据，为了方便知道偏移量，每个分表都使用了自增主键，我们可以看到前一次查询的最小值分别在其他两个表里的位置分别是 322-1 和 297-1，那么对于总体来说这个时间应该是在 322 - 1 + 333 + 297 - 1 = 951，那这样子我只要对后面的数据最多每个表查 1000 - 951 + 5 = 54 条数据再进行合并排序就可以获得最终正确的结果。
    这个就是传说中的二次查询法。
    
+]]>    
+      
+        Java
+      
+      
+        Java
+        Sharding-Jdbc
+      
+      
   
     聊聊一次 brew update 引发的血案
     /2020/06/13/%E8%81%8A%E8%81%8A%E4%B8%80%E6%AC%A1-brew-update-%E5%BC%95%E5%8F%91%E7%9A%84%E8%A1%80%E6%A1%88/
@@ -13976,41 +13976,10 @@ function hiicu64() {
         骑车
       
   
-  
-    聊聊最近平淡的生活之《花束般的恋爱》观后感
-    /2021/12/31/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E3%80%8A%E8%8A%B1%E6%9D%9F%E8%88%AC%E7%9A%84%E6%81%8B%E7%88%B1%E3%80%8B%E8%A7%82%E5%90%8E%E6%84%9F/
-    周末在领导的提议下看了豆瓣的年度榜单，本来感觉没啥心情看的，看到主演有有村架纯就觉得可以看一下，颜值即正义嘛，男主小麦跟女主小娟（后面简称小麦跟小娟）是两个在一次非常偶然的没赶上地铁末班车事件中相识，这里得说下日本这种通宵营业的店好像挺不错的，看着也挺正常，国内估计只有酒吧之类的可以。晚上去的地方是有点暗暗的，好像也有点类似酒吧，旁边有类似于 dj 那种，然后同桌的还有除了男女主的另外一对男女，也是因为没赶上地铁末班车的，但也是陌生人，然后小麦突然看到了有个非常有名的电影人，小娟竟然也认识，然后旁边那对完全不认识，还在那吹自己看过很多电影，比如《肖申克的救赎》，于是男女主都特别鄙夷地看着他们，然后他们又去了另一个有点像泡澡的地方席地而坐，他们发现了自己的鞋子都是一样的，然后在女的去上厕所的时候，小麦暗恋的学姐也来了，然后小麦就去跟学姐他们一起坐了，小娟回来后有点不开心就说去朋友家睡，幸好小麦看出来了（他竟然看出来了，本来以为应该是没填过恋爱很木讷的），就追出去，然后就去了小麦家，到了家小娟发现小麦家的书柜上的书简直就跟她自己家的一模一样，小麦还给小娟吹了头发，一起吃烤饭团，看电影，第二天送小娟上了公交，还约好了一起看木乃伊展，然而并没有交换联系方式，但是他们还是约上了一起看了木乃伊展，在餐馆就出现了片头那一幕的来源，因为餐馆他们想一起听歌，就用有线耳机一人一个耳朵听，但是旁边就有个大叔说“你们是不是不爱音乐，左右耳朵是不一样的，只有一起听才是真正的音乐”这样的话，然后的剧情有点跳，因为是指他们一直在这家餐馆吃饭，中间有他们一起出去玩情节穿插着，也是在这他们确立了关系，可以说主体就是体现了他们非常的合拍和默契，就像一些影评说的，这部电影是说如何跟百分百合拍的人分手，然后就是正常的恋爱开始啪啪啪，一直腻在床上，也没去就业说明会，后面也有讲了一点小麦带着小娟去认识他的朋友，也把小娟介绍给了他们认识，这里算是个小伏笔，后面他们分手也有这里的人的一些关系，接下去的剧情说实话我是不太喜欢的，如果一部八分的电影只是说恋爱被现实打败的话，我觉得在我这是不合格的，但是事实也是这样，小麦其实是有家里的资助，所以后面还是按自己的喜好给一些机构画点插画，小娟则要出去工作，因为小娟家庭观念也是要让她出去有正经工作，用脚指头想也能知道肯定不顺利，然后就是暂时在一家蛋糕店工作，小麦就每天去接小娟，日子过得甜甜蜜蜜，后面小娟在自己的努力下考了个什么资格证，去了一家医院还是什么做前台行政，这中间当然就有父母来见面吃饭了，他们在开始恋爱不久就同居合租了，然后小娟父母就是来说要让她有个正经工作，对男的说的话就是人生就是责任这类的话，而小麦爸爸算是个导火索，因为小麦家里是做烟花生意的，他爸让他就做烟花生意，因为要回老家，并且小麦也不想做，所以就拒绝了，然后他爸就说不给他每个月五万的资助，这也导致了小麦需要去找工作，这个过程也是很辛苦，本来想要年前找好工作，然后事与愿违，后面有一次小娟被同事吐槽怎么从来不去团建，于是她就去了（我以为会拒绝），正在团建的时候小麦给她电话，说找到工作了，是一个创业物流公司这种，这里剧情就是我觉得比较俗套的，小麦各种被虐，累成狗，但是就像小娟爸爸说的话，人生就是责任，所以一直在坚持，但是这样也导致了跟小娟的交流也越来越少，他们原来最爱的漫画，爱玩的游戏，也只剩小娟一个人看，一个人玩，而正是这个时候，小娟说她辞掉了工作，去做一个不是太靠谱的漫画改造的密室逃脱，然后这里其实有一点后面争议很大的，就是这个工作其实是前面小麦介绍给小娟的那些朋友中一个的女朋友介绍的，而在有个剧情就是小娟有一次在这个密室逃脱的老板怀里醒过来，是在 KTV 那样的场景里，这就有很多人觉得小娟是不是出轨了，我觉得其实不那么重要，因为这个离职的事情已经让一切矛盾都摆在眼前，小麦其实是接受这种需要承担责任的生活，也想着要跟小娟结婚，但是小娟似乎还是想要过着那样理想的生活，做自己想做的事情，看自己爱看的漫画，也要小麦能像以前那样一直那么默契的有着相同的爱好，这里的触发点其实还有个是那个小麦的朋友（也就是他女朋友介绍小娟那个不靠谱工作的）的葬礼上，小麦在参加完葬礼后有挺多想倾诉的，而小娟只是想睡了，这个让小麦第二天起来都不想理小娟，只是这里我不太理解，难道这点闹情绪都不能接受吗，所谓的合拍也只是毫无限制的情况下的合拍吧，真正的生活怎么可能如此理想呢，即使没有物质生活的压力，也会有其他的各种压力和限制，在这之后其实小麦想说的是小娟是不是没有想跟自己继续在一起的想法了，而小娟觉得都不说话了，还怎么结婚呢，后面其实导演搞了个小 trick，突然放了异常婚礼，但是不是男女主的，我并不觉得这个桥段很好，在婚礼里男女主都觉得自己想要跟对方说分手了，但是当他们去了最开始一直去的餐馆的时候，一个算是一个现实映照的就是他们一直坐的位子被占了，可能也是导演想通过这个来说明他们已经回不去了，在餐馆交谈的时候，小麦其实是说他们结婚吧，并没有想前面婚礼上预设地要分手，但是小娟放弃了，不想结婚，因为不想过那样的生活了，而小麦觉得可能生活就是那样，不可能一直保持刚恋爱时候的那种感觉，生活就是责任，人生就意味着责任。
    
-
    我的一些观点也在前面说了，恋爱到婚姻，即使物质没问题，经济没问题，也会有各种各样的问题，需要一起去解决，因为结婚就意味着需要相互扶持，而不是各取所需，可能我的要求比较高，后面男女主在分手后还一起住了一段时间，我原来还在想会不会通过这个方式让他们继续去磨合同步，只是我失望了，最后给个打分可能是 5 到 6 分吧，勉强及格，好的影视剧应该源于生活高于生活，这一部可能还比不上生活。
    
-]]>    
-      
-        生活
-      
-      
-        生活
-        看剧
-      
-      
   
     聊聊最近平淡的生活之看《神探狄仁杰》
     /2021/12/19/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E7%9C%8B%E3%80%8A%E7%A5%9E%E6%8E%A2%E7%8B%84%E4%BB%81%E6%9D%B0%E3%80%8B/
     其实最近看的不止这一部，前面看了《继承者们》，《少年包青天》这些，就一起聊下，其中看《继承者们》算是个人比较喜欢，以前就有这种看剧的习惯，这个跟《一生一世》里任嘉伦说自己看《寻秦记》看了几十遍一样，我看喜欢的剧也基本上会看不止五遍，继承者们是有帅哥美女看，而且印象中剧情也挺甜的，一般情况下最好是已经有点遗忘剧情了，因为我个人觉得看剧分两种，无聊了又心情不太好，可以看些这类轻松又看过的剧，可以不完全专心地看剧，另外有心情专心看的时候，可以看一些需要思考，一些探案类的或者烧脑类。
    最近看了《神探狄仁杰》，因为跟前面看的《少年包青天》都是这类古装探案剧，正好有些感想，《少年包青天》算是儿时阴影，本来是不太会去看的，正好有一次有机会跟 LD 一起看了会就也觉得比较有意思就看了下去，不得不说，以前的这些剧还是很不错的，包括剧情和演员，第一部一共是 40 集，看的过程中也发现了大概是五个案子，平均八集一个案子，整体节奏还是比较慢的，但是基本每个案子其实都是构思得很巧妙，很久以前看过但是现在基本不太记得剧情了，每个案子在前面几集的时候基本都猜不到犯案逻辑，但是在看了狄仁杰之后，发现两部剧也有比较大的差别，少年包青天相对来说逻辑性会更强一些，个人主观觉得推理的严谨性更高，可能剧本打磨上更将就一下，而狄仁杰因为要提现他的个人强项，不比少年包青天中有公孙策一时瑜亮的情节，狄仁杰中分工明确，李元芳是个武力担当，曾泰是捧哏的，相对来说是狄仁杰在案子里从始至终地推进案情，有些甚至有些玄乎，会有一些跳脱跟不合理，有些像是狄仁杰的奇遇，不过这些想法是私人的观点，并不是想要评孰优孰劣；第二个感受是不知道是不是年代关系，特别是少年包青天，每个案件的大 boss 基本都不是个完全的坏人，甚至都是比较情有可原的可怜人，因为一些特殊原因，而好几个都是包拯身边的人，这一点其实跟狄仁杰里第一个使团惊魂案件比较类似，虎敬晖也是个人物形象比较丰满的角色，不是个标签化的淡薄形象，跟金木兰的感情和反叛行动在最后都说明的缘由，而且也有随着跟狄仁杰一起办案被其影响感化，最终为了救狄仁杰而被金木兰所杀，只是这样金木兰这个角色就会有些偏执和符号化，当然剧本肯定不是能面面俱到，这样的剧本已经比现在很多流量剧的好很多了。还想到了前阵子看的《指环王》中的白袍萨鲁曼在剧中也是个比较单薄的角色，这样的电影彪炳影史也没办法把个个人物都设计得完整有血有肉，或者说这本来也是应该有侧重点，当然其实我也不觉得指环王就是绝对的最好的，因为相对来说故事情节的复杂性等真的不如西游记，只是在 86 版之后的各种乱七八糟的翻牌和乱拍已经让这个真正的王者神话故事有点力不从心，这里边有部西游记后传是个人还比较喜欢的，虽然武打动作比较鬼畜，但是剧情基本是无敌的，在西游的架构上衍生出来这么完整丰富的故事，人物角色也都有各自的出彩点。
    说回狄仁杰，在这之前也看过徐克拍的几部狄仁杰的电影版，第一部刘德华拍得相对完成度更高，故事性也可圈可点，后面几部就是剧情拉胯，靠特效拉回来一点分，虽说这个也是所谓的狄仁杰宇宙的构思在里面但是现在来看基本是跟西游那些差不多，完全没有整体性可言，打一枪换一个地方，演员也没有延续性，剧情也是前后跳脱，没什么关联跟承上启下，导致质量层次不一，更不用谈什么狄仁杰宇宙了，不过这个事情也是难说，原因很多，现在资本都是更加趋利的，一些需要更长久时间才能有回报的投资是很难获得资本青睐，所以只能将重心投给选择一些流量明星，而本来应该将资源投给剧本打磨的基本就没了，再深入说也没意义了，社会现状就是这样。
    还有一点感想是，以前的剧里的拍摄环境还是比较惨的，看着一些房子，甚至皇宫都是比较破旧的，地面还是石板这种，想想以前的演员的环境再想想现在的，比如成龙说的，以前他拍剧就是啪摔了，问这条有没有过，过了就直接送医院，而不是现在可能手蹭破点皮就大叫，甚至还有饭圈这些破事。
    
-]]>    
-      
-        生活
-      
-      
-        生活
-        看剧
-      
-      
-  
-    聊聊最近平淡的生活之看看老剧
-    /2021/11/21/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E7%9C%8B%E7%9C%8B%E8%80%81%E5%89%A7/
-    最近因为也没什么好看的新剧和综艺所以就看看一些以前看过的老剧，我是个非常念旧的人吧，很多剧都会反反复复地看，一方面之前看过觉得好看的的确是一直记着，还有就是平时工作完了回来就想能放松下，剧情太纠结的，太烧脑的都不喜欢，也就是我常挂在口头的不喜欢看费脑子的剧，跟我不喜欢狼人杀的原因也类似。
    
-
    前面其实是看的太阳的后裔，跟 LD 一起看的，之前其实算是看过一点，但是没有看的很完整，并且很多剧情也忘了，只是这个我我可能看得更少一点，因为最开始的时候觉得男主应该是男二，可能对长得这样的男主并且是这样的人设有点失望，感觉不是特别像个特种兵，但是由于本来也比较火，而且 LD 比较喜欢就从这个开始看了，有两个点是比较想说的
    
-
    韩剧虽然被吐槽的很多，但是很多剧的质量，情节把控还是优于目前非常多国内剧的，相对来说剧情发展的前后承接不是那么硬凹出来的，而且人设都立得住，这个是非常重要的，很多国内剧怎么说呢，就是当爹的看起来就比儿子没大几岁，三四十岁的人去演一个十岁出头的小姑娘，除非容貌异常，比如刘晓庆这种，不然就会觉得导演在把我们观众当傻子。瞬间就没有想看下去的欲望了。
    
-
    再一点就是情节是大众都能接受度比较高的，现在有很多普遍会找一些新奇的视角，比如卖腐，想某某令，两部都叫某某令，这其实是一个点，延伸出去就是跟前面说的一点有点类似，xx 老祖，人看着就二三十，叫 xx 老祖，（喜欢的人轻喷哈）然后名字有一堆，同一个人物一会叫这个名字，一会又叫另一个名字，然后一堆死表情。
    
-
    因为今天有个特殊的事情发生，所以简短的写（shui）一篇了
    
 ]]>    
       
         生活
@@ -14040,19 +14009,20 @@ function hiicu64() {
       
       
   
-    聊聊这次换车牌及其他
-    /2022/02/20/%E8%81%8A%E8%81%8A%E8%BF%99%E6%AC%A1%E6%8D%A2%E8%BD%A6%E7%89%8C%E5%8F%8A%E5%85%B6%E4%BB%96/
-    去年 8 月份运气比较好，摇到了车牌，本来其实应该很早就开始摇的，前面第一次换工作没注意社保断缴了一个月，也是大意失荆州，后面到了 17 年社保满两年了，好像只摇了一次，还是就没摇过，有点忘了，好像是什么原因导致那次也没摇成功，但是后面暂住证就取消了，需要居住证，居住证又要一年及以上的租房合同，并且那会买车以后也不怎么开，住的地方车位还好，但是公司车位一个月要两三千，甚至还是打车上下班比较实惠，所以也没放在心上，后面摇到房以后，也觉得应该准备起来车子，就开始办了居住证，居住证其实还可以用劳动合同，而且办起来也挺快，大概是三四月份开始摇，到 8 月份的某一天收到短信说摇到了，一开始还挺开心，不过心里抱着也不怎么开，也没怎么大放在心上，不过这里有一点就是我把那个照片直接发出去，上面有着我的身份证号，被 LD 说了一顿，以后也应该小心点，但是后面不知道是哪里看了下，说杭州上牌已经需要国六标准的车了，瞬间感觉是空欢喜了，可是有同事说是可以的，我就又打了官方的电话，结果说可以的，要先转籍，然后再做上牌。
    
-
    转籍其实是很方便的，在交警 12123 App 上申请就行了，在转籍以后，需要去实地验车，验车的话，在支付宝-杭州交警生活号里进行预约，找就近的车管所就好，需要准备一些东西，首先是行驶证，机动车登记证书，身份证，居住证，还有车上需要准备的东西是要有三脚架和反光背心，反光背心是最近几个月开始要的，问过之前去验车的只需要三脚架就好了，预约好了的话建议是赶上班时间越早越好，不然过去排队时间要很久，而且人多了以后会很乱，各种插队，而且有很多都是汽车销售，一个销售带着一堆车，我们附近那个进去的小路没一会就堵满车，进去需要先排队，然后扫码，接着交资料，这两个都排着队，如果去晚了就要排很久的队，交完资料才是排队等验车，验车就是打开引擎盖，有人会帮忙拓印发动机车架号，然后验车的会各种检查一下，车里面，还有后备箱，建议车内整理干净点，后备箱不要放杂物，检验完了之后，需要把三脚架跟反光背心放在后备箱盖子上，人在旁边拍个照，然后需要把车牌遮住后再拍个车子的照片，再之后就是去把车牌卸了，这个多吐槽下，那边应该是本来那边师傅帮忙卸车牌，结果他就说是教我们拆，虽然也不算难，但是不排除师傅有在偷懒，完了之后就是把旧车牌交回去，然后需要在手机上（警察叔叔 App）提交各种资料，包括身份证，行驶证，机动车登记证书，提交了之后就等寄车牌过来了。
    
-
    这里面缺失的一个环节就是选号了，选号杭州有两个方式，一种就是根据交管局定期发布的选号号段，可以自定义拼 20 个号，在手机上的交警 12123 App 上可以三个一组的形式提交，如果有没被选走的，就可以预选到这个了，但是这种就是也需要有一定策略，最新出的号段能选中的概率大一点，然后数字全是 8，6 这种的肯定会一早就被选走，然后如果跟我一样可以提前选下尾号，因为尾号数字影响限号，我比较有可能周五回家，所以得避开 5，0 的，第二种就是 50 选一跟以前新车选号一样，就不介绍了。第一种选中了以后可以在前面交还旧车牌的时候填上等着寄过来了，因为我是第一种选中的，第二种也可以在手机上选，也在可以在交还车牌的时候现场选。
    
-
    总体过程其实是 LD 在各种查资料跟帮我跑来跑去，要不是 LD，估计在交管局那边我就懵逼了，各种插队，而且车子开着车子，也不能随便跑，所以建议办这个的时候有个人一起比较好。
    
+    聊聊最近平淡的生活之看看老剧
+    /2021/11/21/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E7%9C%8B%E7%9C%8B%E8%80%81%E5%89%A7/
+    最近因为也没什么好看的新剧和综艺所以就看看一些以前看过的老剧，我是个非常念旧的人吧，很多剧都会反反复复地看，一方面之前看过觉得好看的的确是一直记着，还有就是平时工作完了回来就想能放松下，剧情太纠结的，太烧脑的都不喜欢，也就是我常挂在口头的不喜欢看费脑子的剧，跟我不喜欢狼人杀的原因也类似。
    
+
    前面其实是看的太阳的后裔，跟 LD 一起看的，之前其实算是看过一点，但是没有看的很完整，并且很多剧情也忘了，只是这个我我可能看得更少一点，因为最开始的时候觉得男主应该是男二，可能对长得这样的男主并且是这样的人设有点失望，感觉不是特别像个特种兵，但是由于本来也比较火，而且 LD 比较喜欢就从这个开始看了，有两个点是比较想说的
    
+
    韩剧虽然被吐槽的很多，但是很多剧的质量，情节把控还是优于目前非常多国内剧的，相对来说剧情发展的前后承接不是那么硬凹出来的，而且人设都立得住，这个是非常重要的，很多国内剧怎么说呢，就是当爹的看起来就比儿子没大几岁，三四十岁的人去演一个十岁出头的小姑娘，除非容貌异常，比如刘晓庆这种，不然就会觉得导演在把我们观众当傻子。瞬间就没有想看下去的欲望了。
    
+
    再一点就是情节是大众都能接受度比较高的，现在有很多普遍会找一些新奇的视角，比如卖腐，想某某令，两部都叫某某令，这其实是一个点，延伸出去就是跟前面说的一点有点类似，xx 老祖，人看着就二三十，叫 xx 老祖，（喜欢的人轻喷哈）然后名字有一堆，同一个人物一会叫这个名字，一会又叫另一个名字，然后一堆死表情。
    
+
    因为今天有个特殊的事情发生，所以简短的写（shui）一篇了
    
 ]]>    
       
         生活
       
       
         生活
-        换车牌
+        看剧
       
       
   
@@ -14143,4 +14113,34 @@ function hiicu64() {
         高速
       
   
+  
+    聊聊最近平淡的生活之《花束般的恋爱》观后感
+    /2021/12/31/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E3%80%8A%E8%8A%B1%E6%9D%9F%E8%88%AC%E7%9A%84%E6%81%8B%E7%88%B1%E3%80%8B%E8%A7%82%E5%90%8E%E6%84%9F/
+    周末在领导的提议下看了豆瓣的年度榜单，本来感觉没啥心情看的，看到主演有有村架纯就觉得可以看一下，颜值即正义嘛，男主小麦跟女主小娟（后面简称小麦跟小娟）是两个在一次非常偶然的没赶上地铁末班车事件中相识，这里得说下日本这种通宵营业的店好像挺不错的，看着也挺正常，国内估计只有酒吧之类的可以。晚上去的地方是有点暗暗的，好像也有点类似酒吧，旁边有类似于 dj 那种，然后同桌的还有除了男女主的另外一对男女，也是因为没赶上地铁末班车的，但也是陌生人，然后小麦突然看到了有个非常有名的电影人，小娟竟然也认识，然后旁边那对完全不认识，还在那吹自己看过很多电影，比如《肖申克的救赎》，于是男女主都特别鄙夷地看着他们，然后他们又去了另一个有点像泡澡的地方席地而坐，他们发现了自己的鞋子都是一样的，然后在女的去上厕所的时候，小麦暗恋的学姐也来了，然后小麦就去跟学姐他们一起坐了，小娟回来后有点不开心就说去朋友家睡，幸好小麦看出来了（他竟然看出来了，本来以为应该是没填过恋爱很木讷的），就追出去，然后就去了小麦家，到了家小娟发现小麦家的书柜上的书简直就跟她自己家的一模一样，小麦还给小娟吹了头发，一起吃烤饭团，看电影，第二天送小娟上了公交，还约好了一起看木乃伊展，然而并没有交换联系方式，但是他们还是约上了一起看了木乃伊展，在餐馆就出现了片头那一幕的来源，因为餐馆他们想一起听歌，就用有线耳机一人一个耳朵听，但是旁边就有个大叔说“你们是不是不爱音乐，左右耳朵是不一样的，只有一起听才是真正的音乐”这样的话，然后的剧情有点跳，因为是指他们一直在这家餐馆吃饭，中间有他们一起出去玩情节穿插着，也是在这他们确立了关系，可以说主体就是体现了他们非常的合拍和默契，就像一些影评说的，这部电影是说如何跟百分百合拍的人分手，然后就是正常的恋爱开始啪啪啪，一直腻在床上，也没去就业说明会，后面也有讲了一点小麦带着小娟去认识他的朋友，也把小娟介绍给了他们认识，这里算是个小伏笔，后面他们分手也有这里的人的一些关系，接下去的剧情说实话我是不太喜欢的，如果一部八分的电影只是说恋爱被现实打败的话，我觉得在我这是不合格的，但是事实也是这样，小麦其实是有家里的资助，所以后面还是按自己的喜好给一些机构画点插画，小娟则要出去工作，因为小娟家庭观念也是要让她出去有正经工作，用脚指头想也能知道肯定不顺利，然后就是暂时在一家蛋糕店工作，小麦就每天去接小娟，日子过得甜甜蜜蜜，后面小娟在自己的努力下考了个什么资格证，去了一家医院还是什么做前台行政，这中间当然就有父母来见面吃饭了，他们在开始恋爱不久就同居合租了，然后小娟父母就是来说要让她有个正经工作，对男的说的话就是人生就是责任这类的话，而小麦爸爸算是个导火索，因为小麦家里是做烟花生意的，他爸让他就做烟花生意，因为要回老家，并且小麦也不想做，所以就拒绝了，然后他爸就说不给他每个月五万的资助，这也导致了小麦需要去找工作，这个过程也是很辛苦，本来想要年前找好工作，然后事与愿违，后面有一次小娟被同事吐槽怎么从来不去团建，于是她就去了（我以为会拒绝），正在团建的时候小麦给她电话，说找到工作了，是一个创业物流公司这种，这里剧情就是我觉得比较俗套的，小麦各种被虐，累成狗，但是就像小娟爸爸说的话，人生就是责任，所以一直在坚持，但是这样也导致了跟小娟的交流也越来越少，他们原来最爱的漫画，爱玩的游戏，也只剩小娟一个人看，一个人玩，而正是这个时候，小娟说她辞掉了工作，去做一个不是太靠谱的漫画改造的密室逃脱，然后这里其实有一点后面争议很大的，就是这个工作其实是前面小麦介绍给小娟的那些朋友中一个的女朋友介绍的，而在有个剧情就是小娟有一次在这个密室逃脱的老板怀里醒过来，是在 KTV 那样的场景里，这就有很多人觉得小娟是不是出轨了，我觉得其实不那么重要，因为这个离职的事情已经让一切矛盾都摆在眼前，小麦其实是接受这种需要承担责任的生活，也想着要跟小娟结婚，但是小娟似乎还是想要过着那样理想的生活，做自己想做的事情，看自己爱看的漫画，也要小麦能像以前那样一直那么默契的有着相同的爱好，这里的触发点其实还有个是那个小麦的朋友（也就是他女朋友介绍小娟那个不靠谱工作的）的葬礼上，小麦在参加完葬礼后有挺多想倾诉的，而小娟只是想睡了，这个让小麦第二天起来都不想理小娟，只是这里我不太理解，难道这点闹情绪都不能接受吗，所谓的合拍也只是毫无限制的情况下的合拍吧，真正的生活怎么可能如此理想呢，即使没有物质生活的压力，也会有其他的各种压力和限制，在这之后其实小麦想说的是小娟是不是没有想跟自己继续在一起的想法了，而小娟觉得都不说话了，还怎么结婚呢，后面其实导演搞了个小 trick，突然放了异常婚礼，但是不是男女主的，我并不觉得这个桥段很好，在婚礼里男女主都觉得自己想要跟对方说分手了，但是当他们去了最开始一直去的餐馆的时候，一个算是一个现实映照的就是他们一直坐的位子被占了，可能也是导演想通过这个来说明他们已经回不去了，在餐馆交谈的时候，小麦其实是说他们结婚吧，并没有想前面婚礼上预设地要分手，但是小娟放弃了，不想结婚，因为不想过那样的生活了，而小麦觉得可能生活就是那样，不可能一直保持刚恋爱时候的那种感觉，生活就是责任，人生就意味着责任。
    
+
    我的一些观点也在前面说了，恋爱到婚姻，即使物质没问题，经济没问题，也会有各种各样的问题，需要一起去解决，因为结婚就意味着需要相互扶持，而不是各取所需，可能我的要求比较高，后面男女主在分手后还一起住了一段时间，我原来还在想会不会通过这个方式让他们继续去磨合同步，只是我失望了，最后给个打分可能是 5 到 6 分吧，勉强及格，好的影视剧应该源于生活高于生活，这一部可能还比不上生活。
    
+]]>    
+      
+        生活
+      
+      
+        生活
+        看剧
+      
+      
+  
+    聊聊这次换车牌及其他
+    /2022/02/20/%E8%81%8A%E8%81%8A%E8%BF%99%E6%AC%A1%E6%8D%A2%E8%BD%A6%E7%89%8C%E5%8F%8A%E5%85%B6%E4%BB%96/
+    去年 8 月份运气比较好，摇到了车牌，本来其实应该很早就开始摇的，前面第一次换工作没注意社保断缴了一个月，也是大意失荆州，后面到了 17 年社保满两年了，好像只摇了一次，还是就没摇过，有点忘了，好像是什么原因导致那次也没摇成功，但是后面暂住证就取消了，需要居住证，居住证又要一年及以上的租房合同，并且那会买车以后也不怎么开，住的地方车位还好，但是公司车位一个月要两三千，甚至还是打车上下班比较实惠，所以也没放在心上，后面摇到房以后，也觉得应该准备起来车子，就开始办了居住证，居住证其实还可以用劳动合同，而且办起来也挺快，大概是三四月份开始摇，到 8 月份的某一天收到短信说摇到了，一开始还挺开心，不过心里抱着也不怎么开，也没怎么大放在心上，不过这里有一点就是我把那个照片直接发出去，上面有着我的身份证号，被 LD 说了一顿，以后也应该小心点，但是后面不知道是哪里看了下，说杭州上牌已经需要国六标准的车了，瞬间感觉是空欢喜了，可是有同事说是可以的，我就又打了官方的电话，结果说可以的，要先转籍，然后再做上牌。
    
+
    转籍其实是很方便的，在交警 12123 App 上申请就行了，在转籍以后，需要去实地验车，验车的话，在支付宝-杭州交警生活号里进行预约，找就近的车管所就好，需要准备一些东西，首先是行驶证，机动车登记证书，身份证，居住证，还有车上需要准备的东西是要有三脚架和反光背心，反光背心是最近几个月开始要的，问过之前去验车的只需要三脚架就好了，预约好了的话建议是赶上班时间越早越好，不然过去排队时间要很久，而且人多了以后会很乱，各种插队，而且有很多都是汽车销售，一个销售带着一堆车，我们附近那个进去的小路没一会就堵满车，进去需要先排队，然后扫码，接着交资料，这两个都排着队，如果去晚了就要排很久的队，交完资料才是排队等验车，验车就是打开引擎盖，有人会帮忙拓印发动机车架号，然后验车的会各种检查一下，车里面，还有后备箱，建议车内整理干净点，后备箱不要放杂物，检验完了之后，需要把三脚架跟反光背心放在后备箱盖子上，人在旁边拍个照，然后需要把车牌遮住后再拍个车子的照片，再之后就是去把车牌卸了，这个多吐槽下，那边应该是本来那边师傅帮忙卸车牌，结果他就说是教我们拆，虽然也不算难，但是不排除师傅有在偷懒，完了之后就是把旧车牌交回去，然后需要在手机上（警察叔叔 App）提交各种资料，包括身份证，行驶证，机动车登记证书，提交了之后就等寄车牌过来了。
    
+
    这里面缺失的一个环节就是选号了，选号杭州有两个方式，一种就是根据交管局定期发布的选号号段，可以自定义拼 20 个号，在手机上的交警 12123 App 上可以三个一组的形式提交，如果有没被选走的，就可以预选到这个了，但是这种就是也需要有一定策略，最新出的号段能选中的概率大一点，然后数字全是 8，6 这种的肯定会一早就被选走，然后如果跟我一样可以提前选下尾号，因为尾号数字影响限号，我比较有可能周五回家，所以得避开 5，0 的，第二种就是 50 选一跟以前新车选号一样，就不介绍了。第一种选中了以后可以在前面交还旧车牌的时候填上等着寄过来了，因为我是第一种选中的，第二种也可以在手机上选，也在可以在交还车牌的时候现场选。
    
+
    总体过程其实是 LD 在各种查资料跟帮我跑来跑去，要不是 LD，估计在交管局那边我就懵逼了，各种插队，而且车子开着车子，也不能随便跑，所以建议办这个的时候有个人一起比较好。
    
+]]>    
+      
+        生活
+      
+      
+        生活
+        换车牌
+      
+      
 
diff --git a/sitemap.xml b/sitemap.xml
index 41a5d7a5c4..f55ec75f62 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -1444,7 +1444,7 @@
 
   
     https://nicksxs.me/
-    2022-04-02
+    2022-04-05
     daily
     1.0
   
@@ -1452,1911 +1452,1911 @@
   
   
     https://nicksxs.me/tags/%E7%94%9F%E6%B4%BB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/2020/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/2021/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%8B%96%E6%9B%B4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Java/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/JVM/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/C/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/leetcode/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/java/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Binary-Tree/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/DFS/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%BA%8C%E5%8F%89%E6%A0%91/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%A2%98%E8%A7%A3/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Linked-List/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/
-    2022-04-02
+    https://nicksxs.me/tags/2019/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/2019/
-    2022-04-02
+    https://nicksxs.me/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E6%8A%80%E6%9C%AF/
-    2022-04-02
+    https://nicksxs.me/tags/c/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E8%AF%BB%E4%B9%A6/
-    2022-04-02
+    https://nicksxs.me/tags/%E5%B9%B6%E5%8F%91/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/c/
-    2022-04-02
+    https://nicksxs.me/tags/j-u-c/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E5%B9%B6%E5%8F%91/
-    2022-04-02
+    https://nicksxs.me/tags/aqs/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/j-u-c/
-    2022-04-02
+    https://nicksxs.me/tags/condition/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/aqs/
-    2022-04-02
+    https://nicksxs.me/tags/await/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/condition/
-    2022-04-02
+    https://nicksxs.me/tags/signal/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/await/
-    2022-04-02
+    https://nicksxs.me/tags/lock/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/signal/
-    2022-04-02
+    https://nicksxs.me/tags/unlock/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/lock/
-    2022-04-02
+    https://nicksxs.me/tags/%E6%8A%80%E6%9C%AF/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/unlock/
-    2022-04-02
+    https://nicksxs.me/tags/%E8%AF%BB%E4%B9%A6/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Apollo/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/value/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%B3%A8%E8%A7%A3/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/environment/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Stream/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Comparator/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%8E%92%E5%BA%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/sort/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/nullsfirst/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/Disruptor/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Dubbo/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/RPC/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Filter/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Interceptor/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/AOP/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Spring/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Tomcat/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Servlet/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Web/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/G1/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/GC/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Garbage-First-Collector/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/Disruptor/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%80%92%E5%BD%92/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Preorder-Traversal/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Inorder-Traversal/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%89%8D%E5%BA%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%AD%E5%BA%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/DP/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/stack/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/min-stack/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%9C%80%E5%B0%8F%E6%A0%88/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/leetcode-155/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/linked-list/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Lowest-Common-Ancestor-of-a-Binary-Tree/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/string/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/Intersection-of-Two-Arrays/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Median-of-Two-Sorted-Arrays/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/dp/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%BB%A3%E7%A0%81%E9%A2%98%E8%A7%A3/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Trapping-Rain-Water/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%8E%A5%E9%9B%A8%E6%B0%B4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Leetcode-42/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/Intersection-of-Two-Arrays/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Rotate-Image/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%9F%A9%E9%98%B5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Remove-Duplicates-from-Sorted-List/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/linux/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/grep/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%BD%AC%E4%B9%89/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/mfc/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Maven/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/C/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Redis/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Distributed-Lock/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/hadoop/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/cluster/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/docker/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/mysql/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Docker/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/namespace/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/cgroup/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Dockerfile/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/echo/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/uname/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8F%91%E8%A1%8C%E7%89%88/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Gogs/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Webhook/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8D%9A%E5%AE%A2%EF%BC%8C%E6%96%87%E7%AB%A0/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Mysql/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Mybatis/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Sql%E6%B3%A8%E5%85%A5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%BC%93%E5%AD%98/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/openresty/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/nginx/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/php/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/mq/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/im/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/redis/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%BA%90%E7%A0%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%B7%98%E6%B1%B0%E7%AD%96%E7%95%A5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%BA%94%E7%94%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Evict/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%BF%87%E6%9C%9F%E7%AD%96%E7%95%A5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Rust/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%89%80%E6%9C%89%E6%9D%83/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%86%85%E5%AD%98%E5%88%86%E5%B8%83/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%96%B0%E8%AF%AD%E8%A8%80/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8F%AF%E5%8F%98%E5%BC%95%E7%94%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%8D%E5%8F%AF%E5%8F%98%E5%BC%95%E7%94%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%88%87%E7%89%87/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/spark/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/python/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Spring-Event/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/websocket/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/swoole/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/WordPress/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B0%8F%E6%8A%80%E5%B7%A7/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/gc/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%A0%87%E8%AE%B0%E6%95%B4%E7%90%86/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/jvm/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/MQ/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/RocketMQ/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%89%8A%E5%B3%B0%E5%A1%AB%E8%B0%B7/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%AD%E9%97%B4%E4%BB%B6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/ssh/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%90%90%E6%A7%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%96%AB%E6%83%85/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%BE%8E%E5%9B%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4%E8%BD%A6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8F%A3%E7%BD%A9/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%9D%80%E4%BA%BA%E8%AF%9B%E5%BF%83/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%BC%80%E8%BD%A6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8A%A0%E5%A1%9E/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%B3%9F%E5%BF%83%E4%BA%8B/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%A7%84%E5%88%99/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%B7%AF%E6%94%BF%E8%A7%84%E5%88%92/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%9D%AD%E5%B7%9E/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%81%A5%E5%BA%B7%E7%A0%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%89%93%E5%8D%A1/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B9%B8%E7%A6%8F%E4%BA%86%E5%90%97/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%B6%B3%E7%90%83/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/git/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/scp/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%BF%90%E5%8A%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%87%8F%E8%82%A5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%B7%91%E6%AD%A5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B9%B2%E6%B4%BB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%BD%B1%E8%AF%84/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%AF%84%E7%94%9F%E8%99%AB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E5%AD%97%E7%AC%A6%E9%9B%86/
-    2022-04-02
+    https://nicksxs.me/tags/git/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E7%BC%96%E7%A0%81/
-    2022-04-02
+    https://nicksxs.me/tags/scp/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/utf8/
-    2022-04-02
+    https://nicksxs.me/tags/DefaultMQPushConsumer/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/utf8mb4/
-    2022-04-02
+    https://nicksxs.me/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/utf8mb4-0900-ai-ci/
-    2022-04-02
+    https://nicksxs.me/tags/NameServer/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/utf8mb4-unicode-ci/
-    2022-04-02
+    https://nicksxs.me/tags/SpringBoot/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/utf8mb4-general-ci/
-    2022-04-02
+    https://nicksxs.me/tags/Druid/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/DefaultMQPushConsumer/
-    2022-04-02
+    https://nicksxs.me/tags/%E6%95%B0%E6%8D%AE%E6%BA%90%E5%8A%A8%E6%80%81%E5%88%87%E6%8D%A2/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/NameServer/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/SpringBoot/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/cglib/
-    2022-04-02
+    https://nicksxs.me/tags/cglib/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%BA%8B%E5%8A%A1/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/Druid/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/tags/%E6%95%B0%E6%8D%AE%E6%BA%90%E5%8A%A8%E6%80%81%E5%88%87%E6%8D%A2/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%9C%E4%BA%AC%E5%A5%A5%E8%BF%90%E4%BC%9A/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%BE%E9%87%8D/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B0%84%E5%87%BB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B9%92%E4%B9%93%E7%90%83/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%B7%B3%E6%B0%B4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/SPI/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Adaptive/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%87%AA%E9%80%82%E5%BA%94%E6%8B%93%E5%B1%95/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Synchronized/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%81%8F%E5%90%91%E9%94%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%BD%BB%E9%87%8F%E7%BA%A7%E9%94%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%87%8D%E9%87%8F%E7%BA%A7%E9%94%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%87%AA%E6%97%8B/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%B1%BB%E5%8A%A0%E8%BD%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8A%A0%E8%BD%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%AA%8C%E8%AF%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%87%86%E5%A4%87/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%A7%A3%E6%9E%90/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%88%9D%E5%A7%8B%E5%8C%96/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%93%BE%E6%8E%A5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8F%8C%E4%BA%B2%E5%A7%94%E6%B4%BE/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/JPS/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/JStack/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/JMap/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/top/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/%E5%AD%97%E7%AC%A6%E9%9B%86/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/%E7%BC%96%E7%A0%81/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/utf8/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/utf8mb4/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/utf8mb4-0900-ai-ci/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/utf8mb4-unicode-ci/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/tags/utf8mb4-general-ci/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Broker/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Sharding-Jdbc/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/ThreadPool/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%BA%BF%E7%A8%8B%E6%B1%A0/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/FixedThreadPool/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/LimitedThreadPool/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/EagerThreadPool/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/CachedThreadPool/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/mvcc/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/read-view/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/gap-lock/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/next-key-lock/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B9%BB%E8%AF%BB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%B4%A2%E5%BC%95/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/is-null/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/is-not-null/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/procedure/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E7%A9%BF%E9%80%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E5%87%BB%E7%A9%BF/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E9%9B%AA%E5%B4%A9/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/bloom-filter/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%BA%92%E6%96%A5%E9%94%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Design-Patterns/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8D%95%E4%BE%8B/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Singleton/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%87%AA%E5%8A%A8%E8%A3%85%E9%85%8D/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/AutoConfiguration/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Mac/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/PHP/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Homebrew/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/icu4c/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/zsh/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/ThreadLocal/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%BC%B1%E5%BC%95%E7%94%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/WeakReference/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%97%85%E6%B8%B8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%8E%A6%E9%97%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%AD%E5%B1%B1%E8%B7%AF/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%B1%80%E5%8F%A3%E8%A1%97/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%BC%93%E6%B5%AA%E5%B1%BF/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%9B%BE%E5%8E%9D%E5%9E%B5/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%A4%8D%E7%89%A9%E5%9B%AD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%A9%AC%E6%88%8F%E5%9B%A2/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%B2%99%E8%8C%B6%E9%9D%A2/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%B5%B7%E8%9B%8E%E7%85%8E/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E6%89%B6%E6%A2%AF/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%B8%A9%E8%B8%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%AE%89%E5%85%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%94%B5%E7%93%B6%E8%BD%A6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/Thread-dump/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/2PC/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/3PC/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E9%AA%91%E8%BD%A6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E7%9C%8B%E5%89%A7/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%A3%85%E7%94%B5%E8%84%91/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E8%80%81%E7%94%B5%E8%84%91/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/360-%E5%85%A8%E5%AE%B6%E6%A1%B6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/tags/%E4%BF%AE%E7%94%B5%E8%84%91%E7%9A%84/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E6%8D%A2%E8%BD%A6%E7%89%8C/
-    2022-04-02
+    https://nicksxs.me/tags/%E7%9C%8B%E4%B9%A6/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E7%9C%8B%E4%B9%A6/
-    2022-04-02
+    https://nicksxs.me/tags/%E9%AB%98%E9%80%9F/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/tags/%E9%AB%98%E9%80%9F/
-    2022-04-02
+    https://nicksxs.me/tags/%E6%8D%A2%E8%BD%A6%E7%89%8C/
+    2022-04-05
     weekly
     0.2
   
@@ -3365,1022 +3365,1022 @@
   
   
     https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
-    2022-04-02
+    https://nicksxs.me/categories/Java/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/
-    2022-04-02
+    https://nicksxs.me/categories/Java/leetcode/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/JVM/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/leetcode/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/GC/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Binary-Tree/
-    2022-04-02
+    https://nicksxs.me/categories/Linked-List/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Linked-List/
-    2022-04-02
+    https://nicksxs.me/categories/Binary-Tree/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/C/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2019/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/leetcode/java/
-    2022-04-02
+    https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/leetcode/java/Binary-Tree/
-    2022-04-02
+    https://nicksxs.me/categories/C/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/leetcode/java/Linked-List/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/leetcode/java/Binary-Tree/DFS/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/
-    2022-04-02
+    https://nicksxs.me/categories/Java/%E5%B9%B6%E5%8F%91/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2019/
-    2022-04-02
+    https://nicksxs.me/categories/java/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E6%9D%91%E4%B8%8A%E6%98%A5%E6%A0%91/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Apollo/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/%E5%B9%B6%E5%8F%91/
-    2022-04-02
+    https://nicksxs.me/categories/Java/%E9%9B%86%E5%90%88/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2020/
-    2022-04-02
+    https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E6%9D%91%E4%B8%8A%E6%98%A5%E6%A0%91/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/java/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Dubbo/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Apollo/
-    2022-04-02
+    https://nicksxs.me/categories/Filter/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2021/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2020/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/%E9%9B%86%E5%90%88/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/Linked-List/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Dubbo/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2021/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Filter/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/Binary-Tree/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/leetcode/
-    2022-04-02
+    https://nicksxs.me/categories/DP/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Apollo/value/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/categories/DP/
-    2022-04-02
+    https://nicksxs.me/categories/stack/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/stack/
-    2022-04-02
+    https://nicksxs.me/categories/Java/leetcode/Lowest-Common-Ancestor-of-a-Binary-Tree/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/linked-list/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Interceptor-AOP/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%AD%97%E7%AC%A6%E4%B8%B2-online/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%AD%97%E7%AC%A6%E4%B8%B2-online/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Apollo/value/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/leetcode/Rotate-Image/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Linux/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/Maven/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Redis/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/categories/leetcode/java/DP/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/leetcode/java/stack/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/categories/Java/leetcode/Lowest-Common-Ancestor-of-a-Binary-Tree/
-    2022-04-02
+    https://nicksxs.me/categories/Interceptor-AOP/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/data-analysis/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/docker/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/categories/leetcode/java/linked-list/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Docker/
-    2022-04-02
-    weekly
-    0.2
-  
-  
-  
-    https://nicksxs.me/categories/Spring/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/leetcode/java/string/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/Binary-Tree/DFS/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/Mybatis/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/DP/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/nginx/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/php/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/redis/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Redis/Distributed-Lock/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/stack/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Redis/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/linked-list/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Spring/
-    2022-04-02
+    https://nicksxs.me/categories/leetcode/java/string/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Docker/%E4%BB%8B%E7%BB%8D/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Spring/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/gc/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/
-    2022-04-02
+    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/MQ/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/ssh/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Spring/Servlet/
-    2022-04-02
+    https://nicksxs.me/categories/Redis/Distributed-Lock/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%85%AC%E4%BA%A4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E7%99%BD%E5%B2%A9%E6%9D%BE/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/git/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/shell/
-    2022-04-02
+    https://nicksxs.me/categories/Spring/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Mysql/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/
-    2022-04-02
+    https://nicksxs.me/categories/Docker/%E4%BB%8B%E7%BB%8D/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Mybatis/
-    2022-04-02
+    https://nicksxs.me/categories/git/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/grep/
-    2022-04-02
+    https://nicksxs.me/categories/shell/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/SpringBoot/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/C/
-    2022-04-02
+    https://nicksxs.me/categories/Mysql/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Redis/%E6%BA%90%E7%A0%81/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Dubbo/RPC/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Dubbo/RPC/
-    2022-04-02
+    https://nicksxs.me/categories/Mybatis/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo-RPC/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/%E7%B1%BB%E5%8A%A0%E8%BD%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Thread-dump/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/top/
-    2022-04-02
+    https://nicksxs.me/categories/Dubbo-%E7%BA%BF%E7%A8%8B%E6%B1%A0/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Dubbo-%E7%BA%BF%E7%A8%8B%E6%B1%A0/
-    2022-04-02
+    https://nicksxs.me/categories/Redis/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Redis/%E5%BA%94%E7%94%A8/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/Rust/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Design-Patterns/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Design-Patterns/
-    2022-04-02
+    https://nicksxs.me/categories/SpringBoot/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Mac/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/SpringBoot/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E6%97%85%E6%B8%B8/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E6%97%85%E6%B8%B8/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Rust/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BC%80%E8%BD%A6/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
-    2022-04-02
+    https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/Rust/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BC%80%E8%BD%A6/
-    2022-04-02
+    https://nicksxs.me/categories/Rust/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/gc/jvm/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/MQ/RocketMQ/
-    2022-04-02
+    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/grep/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/echo/
-    2022-04-02
+    https://nicksxs.me/categories/MQ/RocketMQ/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/ssh/%E6%8A%80%E5%B7%A7/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/%E7%96%AB%E6%83%85/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Spring/Servlet/Interceptor/
-    2022-04-02
+    https://nicksxs.me/categories/C/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E7%99%BD%E5%B2%A9%E6%9D%BE/%E5%B9%B8%E7%A6%8F%E4%BA%86%E5%90%97/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/git/%E5%B0%8F%E6%8A%80%E5%B7%A7/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/%E8%B7%91%E6%AD%A5/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/shell/%E5%B0%8F%E6%8A%80%E5%B7%A7/
-    2022-04-02
+    https://nicksxs.me/categories/Spring/Servlet/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/%E8%B7%91%E6%AD%A5/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/2020/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Mysql/Sql%E6%B3%A8%E5%85%A5/
-    2022-04-02
+    https://nicksxs.me/categories/git/%E5%B0%8F%E6%8A%80%E5%B7%A7/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/2020/
-    2022-04-02
+    https://nicksxs.me/categories/shell/%E5%B0%8F%E6%8A%80%E5%B7%A7/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Mybatis/%E7%BC%93%E5%AD%98/
-    2022-04-02
+    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/echo/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/
-    2022-04-02
+    https://nicksxs.me/categories/Mysql/Sql%E6%B3%A8%E5%85%A5/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/C/Redis/
-    2022-04-02
+    https://nicksxs.me/categories/Java/Dubbo/RPC/SPI/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Java/Dubbo/RPC/SPI/
-    2022-04-02
+    https://nicksxs.me/categories/Mybatis/%E7%BC%93%E5%AD%98/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/
-    2022-04-02
+    https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/top/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/
-    2022-04-02
+    https://nicksxs.me/categories/%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Mysql/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/categories/Redis/%E6%BA%90%E7%A0%81/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Mysql/%E7%B4%A2%E5%BC%95/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Redis/%E7%BC%93%E5%AD%98/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Java/Singleton/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Mac/PHP/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Docker/%E5%8F%91%E8%A1%8C%E7%89%88%E6%9C%AC/
-    2022-04-02
+    https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/%E7%96%AB%E6%83%85/%E7%BE%8E%E5%9B%BD/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Spring/Servlet/Interceptor/AOP/
-    2022-04-02
+    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/%E7%96%AB%E6%83%85/%E5%8F%A3%E7%BD%A9/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/%E7%96%AB%E6%83%85/%E5%8F%A3%E7%BD%A9/
-    2022-04-02
+    https://nicksxs.me/categories/C/Redis/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/%E8%B7%91%E6%AD%A5/%E5%B9%B2%E6%B4%BB/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/Spring/Mybatis/
-    2022-04-02
+    https://nicksxs.me/categories/Spring/Servlet/Interceptor/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/%E6%9F%A5%E6%97%A5%E5%BF%97/
-    2022-04-02
+    https://nicksxs.me/categories/MQ/RocketMQ/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/MQ/RocketMQ/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
-    2022-04-02
+    https://nicksxs.me/categories/Docker/%E5%8F%91%E8%A1%8C%E7%89%88%E6%9C%AC/
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/categories/Spring/Mybatis/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B7%A5%E5%85%B7/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/
+    2022-04-05
     weekly
     0.2
   
   
   
-    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/%E6%8E%92%E5%BA%8F/
-    2022-04-02
+    https://nicksxs.me/categories/%E5%B7%A5%E5%85%B7/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Mysql/%E6%BA%90%E7%A0%81/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/C/Mysql/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Mac/Homebrew/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/%E6%9F%A5%E6%97%A5%E5%BF%97/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/RocketMQ/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/categories/Spring/Servlet/Interceptor/AOP/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo/SPI/
-    2022-04-02
+    2022-04-05
+    weekly
+    0.2
+  
+  
+  
+    https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/%E6%8E%92%E5%BA%8F/
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/ThreadPool/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/%E7%A9%BF%E9%80%8F/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/PHP/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E4%B8%AD%E9%97%B4%E4%BB%B6/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/Dubbo/SPI/Adaptive/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/%E7%A9%BF%E9%80%8F/%E5%87%BB%E7%A9%BF/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/PHP/icu4c/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E4%B8%AD%E9%97%B4%E4%BB%B6/RocketMQ/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
   
   
     https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/%E7%A9%BF%E9%80%8F/%E5%87%BB%E7%A9%BF/%E9%9B%AA%E5%B4%A9/
-    2022-04-02
+    2022-04-05
     weekly
     0.2
   
diff --git a/tags/JVM/index.html b/tags/JVM/index.html
index d5708ccf21..9cd740d283 100644
--- a/tags/JVM/index.html
+++ b/tags/JVM/index.html
@@ -1 +1 @@
-标签: jvm | Nicksxs's Blog
      
    Nicksxs's Blog
    What hurts more, the pain of hard work or the pain of regret?
      
     0%
    jvm 标签
    2021
    © 2022  Nicksxs
       
    
\ No newline at end of file
+标签: jvm | Nicksxs's Blog
      
    Nicksxs's Blog
    What hurts more, the pain of hard work or the pain of regret?
      
     0%
    jvm 标签
    2021
    © 2022  Nicksxs
       
    urce/js/third-party/quicklink.min.js">
\ No newline at end of file
diff --git a/tags/mysql/index.html b/tags/mysql/index.html
index 69bf3854f5..e993b1b375 100644
--- a/tags/mysql/index.html
+++ b/tags/mysql/index.html
@@ -1 +1 @@
-标签: Mysql | Nicksxs's Blog
      
    Nicksxs's Blog
    What hurts more, the pain of hard work or the pain of regret?
      
     0%
    Mysql 标签
    2020
    © 2022  Nicksxs
       
    
\ No newline at end of file
+标签: Mysql | Nicksxs's Blog
      
    Nicksxs's Blog
    What hurts more, the pain of hard work or the pain of regret?
      
     0%
    Mysql 标签
    2020
    © 2022  Nicksxs
       
    lozad.min.js" integrity="sha256-mOFREFhqmHeQbXpK2lp4nA3qooVgACfh88fpJftLBbc=" crossorigin="anonymous">
\ No newline at end of file
diff --git a/tags/php/index.html b/tags/php/index.html
index 04a5a92059..2e4cef87a7 100644
--- a/tags/php/index.html
+++ b/tags/php/index.html
@@ -1 +1 @@
-标签: PHP | Nicksxs's Blog
      
    Nicksxs's Blog
    What hurts more, the pain of hard work or the pain of regret?
      
     0%
    PHP 标签
    2020
    © 2022  Nicksxs
       
    
\ No newline at end of file
+标签: PHP | Nicksxs's Blog
      
    Nicksxs's Blog
    What hurts more, the pain of hard work or the pain of regret?
      
     0%
    PHP 标签
    2020
    © 2022  Nicksxs
       
    ipt src="https://cdn.jsdelivr.net/npm/hexo-theme-next@8.10.0/source/js/third-party/quicklink.min.js">
\ No newline at end of file