最近做 docker 系列，会经常进到 docker 内部，如上一篇介绍的，这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包，如果构建镜像的时候没有替换源的话，因为你懂的原因，在内部想编辑下东西要安装 vim 就会很慢很慢，thousand years later~
而且如果在容器内部想改源配置的话也要编辑器，就陷入了一个鸡生蛋，跟蛋生鸡的问题中，对于 linux 大神来说应该有一万种方法解决这个问题，对于我这个渣渣来说可能只想到了这个土方法，先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题，这个 sources.list 一般不止一行，直接 echo 的话就解析不了了，不过 echo 可以支持”\n”转义，就是加-e
看一下解释和示例
还有一点也是在这个时候要安装 vim 之类的，得知道是什么镜像底包，如果是用 uname 指令，其实看到的是宿主机的系统，得用cat /etc/issue
这里稍稍记一下
最近做 docker 系列，会经常进到 docker 内部，如上一篇介绍的，这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包，如果构建镜像的时候没有替换源的话，因为你懂的原因，在内部想编辑下东西要安装 vim 就会很慢很慢，thousand years later~
而且如果在容器内部想改源配置的话也要编辑器，就陷入了一个鸡生蛋，跟蛋生鸡的问题中，对于 linux 大神来说应该有一万种方法解决这个问题，对于我这个渣渣来说可能只想到了这个土方法，先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题，这个 sources.list 一般不止一行，直接 echo 的话就解析不了了，不过 echo 可以支持”\n”转义，就是加-e
看一下解释和示例
还有一点也是在这个时候要安装 vim 之类的，得知道是什么镜像底包，如果是用 uname 指令，其实看到的是宿主机的系统，得用cat /etc/issue
这里稍稍记一下
很久以前，有位面试官问到，你知道 mysql 的事务隔离级别吗，“额 O__O …，不太清楚”，完了之后我就去网上找相关的文章，找到了这篇MySQL 四种事务隔离级的说明, 文章写得特别好，看了这个就懂了各个事务隔离级别都是啥，不过看了这个之后多思考一下的话还是会发现问题，这么神奇的事务隔离级别是怎么实现的呢
其中 innodb 的事务隔离用到了标题里说到的 mvcc，Multiversion concurrency control, 直译过来就是多版本并发控制，先不讲这个究竟是个啥，考虑下如果纯猜测，这个事务隔离级别应该会是怎么样实现呢，愚钝的我想了下，可以在事务开始的时候拷贝一个表，这个可以支持 RR 级别，RC 级别就不支持了，而且要是个非常大的表，想想就不可行
腆着脸说虽然这个不可行，但是思路是对的，具体实行起来需要做一系列（肥肠多）的改动，首先根据我的理解，其实这个拷贝一个表是变成拷贝一条记录，但是如果有多个事务，那就得拷贝多次，这个问题其实可以借助版本管理系统来解释，在用版本管理系统，git 之类的之前，很原始的可能是开发完一个功能后，就打个压缩包用时间等信息命名，然后如果后面要找回这个就直接用这个压缩包的就行了，后来有了 svn，git 中心式和分布式的版本管理系统，它的一个特点是粒度可以控制到文件和代码行级别，对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别，可能之前很多人都了解过，数据库的一行记录除了我们用户自定义的字段，还有一些额外的字段，去源码data0type.h里捞一下
/* Precise data types for system columns and the length of those columns;
+聊聊 mysql 的 MVCC | Nicksxs's Blog 0%聊聊 mysql 的 MVCC
很久以前，有位面试官问到，你知道 mysql 的事务隔离级别吗，“额 O__O …，不太清楚”，完了之后我就去网上找相关的文章，找到了这篇MySQL 四种事务隔离级的说明, 文章写得特别好，看了这个就懂了各个事务隔离级别都是啥，不过看了这个之后多思考一下的话还是会发现问题，这么神奇的事务隔离级别是怎么实现的呢
其中 innodb 的事务隔离用到了标题里说到的 mvcc，Multiversion concurrency control, 直译过来就是多版本并发控制，先不讲这个究竟是个啥，考虑下如果纯猜测，这个事务隔离级别应该会是怎么样实现呢，愚钝的我想了下，可以在事务开始的时候拷贝一个表，这个可以支持 RR 级别，RC 级别就不支持了，而且要是个非常大的表，想想就不可行
腆着脸说虽然这个不可行，但是思路是对的，具体实行起来需要做一系列（肥肠多）的改动，首先根据我的理解，其实这个拷贝一个表是变成拷贝一条记录，但是如果有多个事务，那就得拷贝多次，这个问题其实可以借助版本管理系统来解释，在用版本管理系统，git 之类的之前，很原始的可能是开发完一个功能后，就打个压缩包用时间等信息命名，然后如果后面要找回这个就直接用这个压缩包的就行了，后来有了 svn，git 中心式和分布式的版本管理系统，它的一个特点是粒度可以控制到文件和代码行级别，对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别，可能之前很多人都了解过，数据库的一行记录除了我们用户自定义的字段，还有一些额外的字段，去源码data0type.h里捞一下
/* Precise data types for system columns and the length of those columns;
NOTE: the values must run from 0 up in the order given! All codes must
be less than 256 */
#define DATA_ROW_ID 0 /* row id: a 48-bit integer */
diff --git a/2020/05/02/聊聊-mysql-的-MVCC-续篇/index.html b/2020/05/02/聊聊-mysql-的-MVCC-续篇/index.html
index 6bbe7fcd16..ea38215315 100644
--- a/2020/05/02/聊聊-mysql-的-MVCC-续篇/index.html
+++ b/2020/05/02/聊聊-mysql-的-MVCC-续篇/index.html
@@ -1,4 +1,4 @@
-聊聊 mysql 的 MVCC 续篇 | Nicksxs's Blog 0%聊聊 mysql 的 MVCC 续篇
上一篇聊了mysql 的 innodb 引擎基于 read view 实现的 mvcc 和事务隔离级别，可能有些细心的小伙伴会发现一些问题，第一个是在 RC 级别下的事务提交后的可见性，这里涉及到了三个参数，m_low_limit_id，m_up_limit_id，m_ids，之前看到知乎的一篇写的非常不错的文章，但是就在这一点上似乎有点疑惑，这里基于源码和注释来解释下这个问题
/**
+聊聊 mysql 的 MVCC 续篇 | Nicksxs's Blog 0%聊聊 mysql 的 MVCC 续篇
上一篇聊了mysql 的 innodb 引擎基于 read view 实现的 mvcc 和事务隔离级别，可能有些细心的小伙伴会发现一些问题，第一个是在 RC 级别下的事务提交后的可见性，这里涉及到了三个参数，m_low_limit_id，m_up_limit_id，m_ids，之前看到知乎的一篇写的非常不错的文章，但是就在这一点上似乎有点疑惑，这里基于源码和注释来解释下这个问题
/**
Opens a read view where exactly the transactions serialized before this
point in time are seen in the view.
@param id Creator transaction id */
diff --git a/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/index.html b/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/index.html
index 806144d8e8..545af8753b 100644
--- a/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/index.html
+++ b/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/index.html
@@ -1 +1 @@
-聊聊 mysql 的 MVCC 续续篇之锁分析 | Nicksxs's Blog 0%聊聊 mysql 的 MVCC 续续篇之锁分析
看完前面两篇水文之后，感觉不得不来分析下 mysql 的锁了，其实前面说到幻读的时候是有个前提没提到的，比如一个select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的，当然这里是指在 RR 或者 RC 隔离级别下，
看一段 mysql官方文档
SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
纯粹的这种一致性读，实际读取的是快照，也就是基于 read view 的读取方式，除非当前隔离级别是SERIALIZABLE
但是对于以下几类
select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;
除了第一条是 S 锁之外，其他都是 X 排他锁，这边在顺带下，S 锁表示共享锁， X 表示独占锁，同为 S 锁之间不冲突，S 与 X，X 与 S，X 与 X 之间都冲突，也就是加了前者，后者就加不上了
我们知道对于 RC 级别会出现幻读现象，对于 RR 级别不会出现，主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁，那么是不是 RR 级别下以上所有的都是要加 gap 锁呢，当然不是
举个例子，RR 事务隔离级别下，table1 有个主键id 字段
select * from table1 where id = 10 for update
这条语句要加 gap 锁吗？
答案是不需要，这里其实算是我看了这么久的一点自己的理解，啥时候要加 gap 锁，判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致，我上面这条查询语句，在什么情况下会出现查询结果数量不一致呢，只要在这条记录被更新或者删除的时候，有没有可能我第一次查出来一条，第二次变成两条了呢，不可能，因为是主键索引。
再变更下这个题的条件，当 id 不是主键，但是是唯一索引，这样需要怎么加锁，注意问题是怎么加锁，不是需不需要加 gap 锁，这里呢就是稍微延伸一下，把聚簇索引（主键索引）和二级索引带一下，当 id 不是主键，说明是个二级索引，但是它是唯一索引，体会下，首先对于 id = 10这个二级索引肯定要加锁，要不要锁 gap 呢，不用，因为是唯一索引，id = 10 只可能有这一条记录，然后呢，这样是不是就好了，还不行，因为啥，因为它是二级索引，对应的主键索引的记录才是真正的数据，万一被更新掉了咋办，所以在 id = 10 对应的主键索引上也需要加上锁（默认都是 record lock行锁），那主键索引上要不要加 gap 呢，也不用，也是精确定位到这一条记录
最后呢，当 id 不是主键，也不是唯一索引，只是个普通的索引，这里就需要大名鼎鼎的 gap 锁了，
是时候画个图了
![]()
其实核心的目的还是不让这个 id=10 的记录不会出现幻读，那么就需要在 id 这个索引上加上三个 gap 锁，主键索引上就不用了，在 id 索引上已经控制住了id = 10 不会出现幻读，主键索引上这两条对应的记录已经锁了，所以就这样 OK 了
聊聊 mysql 的 MVCC 续续篇之锁分析 | Nicksxs's Blog 0%聊聊 mysql 的 MVCC 续续篇之锁分析
看完前面两篇水文之后，感觉不得不来分析下 mysql 的锁了，其实前面说到幻读的时候是有个前提没提到的，比如一个select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的，当然这里是指在 RR 或者 RC 隔离级别下，
看一段 mysql官方文档
SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
纯粹的这种一致性读，实际读取的是快照，也就是基于 read view 的读取方式，除非当前隔离级别是SERIALIZABLE
但是对于以下几类
select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;
除了第一条是 S 锁之外，其他都是 X 排他锁，这边在顺带下，S 锁表示共享锁， X 表示独占锁，同为 S 锁之间不冲突，S 与 X，X 与 S，X 与 X 之间都冲突，也就是加了前者，后者就加不上了
我们知道对于 RC 级别会出现幻读现象，对于 RR 级别不会出现，主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁，那么是不是 RR 级别下以上所有的都是要加 gap 锁呢，当然不是
举个例子，RR 事务隔离级别下，table1 有个主键id 字段
select * from table1 where id = 10 for update
这条语句要加 gap 锁吗？
答案是不需要，这里其实算是我看了这么久的一点自己的理解，啥时候要加 gap 锁，判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致，我上面这条查询语句，在什么情况下会出现查询结果数量不一致呢，只要在这条记录被更新或者删除的时候，有没有可能我第一次查出来一条，第二次变成两条了呢，不可能，因为是主键索引。
再变更下这个题的条件，当 id 不是主键，但是是唯一索引，这样需要怎么加锁，注意问题是怎么加锁，不是需不需要加 gap 锁，这里呢就是稍微延伸一下，把聚簇索引（主键索引）和二级索引带一下，当 id 不是主键，说明是个二级索引，但是它是唯一索引，体会下，首先对于 id = 10这个二级索引肯定要加锁，要不要锁 gap 呢，不用，因为是唯一索引，id = 10 只可能有这一条记录，然后呢，这样是不是就好了，还不行，因为啥，因为它是二级索引，对应的主键索引的记录才是真正的数据，万一被更新掉了咋办，所以在 id = 10 对应的主键索引上也需要加上锁（默认都是 record lock行锁），那主键索引上要不要加 gap 呢，也不用，也是精确定位到这一条记录
最后呢，当 id 不是主键，也不是唯一索引，只是个普通的索引，这里就需要大名鼎鼎的 gap 锁了，
是时候画个图了
![]()
其实核心的目的还是不让这个 id=10 的记录不会出现幻读，那么就需要在 id 这个索引上加上三个 gap 锁，主键索引上就不用了，在 id 索引上已经控制住了id = 10 不会出现幻读，主键索引上这两条对应的记录已经锁了，所以就这样 OK 了
Linux 下 grep 命令的一点小技巧 | Nicksxs's Blog 0%Linux 下 grep 命令的一点小技巧
用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，
譬如
+Linux 下 grep 命令的一点小技巧 | Nicksxs's Blog 0%Linux 下 grep 命令的一点小技巧
用了比较久的 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 5d1ac69808..732c7d2873 100644
--- a/2020/09/06/mybatis-的-和-是有啥区别/index.html
+++ b/2020/09/06/mybatis-的-和-是有啥区别/index.html
@@ -1,4 +1,4 @@
-mybatis 的 $ 和 # 是有啥区别 | Nicksxs's Blog 0%mybatis 的 $ 和 # 是有啥区别
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条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 0%mybatis 的 $ 和 # 是有啥区别
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条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 148b7a6988..e457a39303 100644
--- a/2020/10/03/mybatis-的缓存是怎么回事/index.html
+++ b/2020/10/03/mybatis-的缓存是怎么回事/index.html
@@ -1,4 +1,4 @@
-mybatis 的缓存是怎么回事 | Nicksxs's Blog 0%mybatis 的缓存是怎么回事
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 0%mybatis 的缓存是怎么回事
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/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/index.html b/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/index.html
index 989c0bedba..6af77ef8ad 100644
--- a/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/index.html
+++ b/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/index.html
@@ -1,4 +1,4 @@
-Leetcode 104 二叉树的最大深度(Maximum Depth of Binary Tree) 题解分析 | Nicksxs's Blog 0%Leetcode 234 回文链表(Palindrome Linked List) 题解分析 | Nicksxs's Blog 0%Leetcode 105 从前序与中序遍历序列构造二叉树(Construct Binary Tree from Preorder and Inorder Traversal) 题解分析 | Nicksxs's Blog 0%聊聊 mysql 索引的一些细节 | Nicksxs's Blog 0%聊聊 mysql 索引的一些细节
前几天同事问了我个 mysql 索引的问题，虽然大概知道，但是还是想来实践下，就是 is null，is not null 这类查询是否能用索引，可能之前有些网上的文章说都是不能用索引，但是其实不是，我们来看个小试验
CREATE TABLE `null_index_t` (
+聊聊 mysql 索引的一些细节 | Nicksxs's Blog 0%聊聊 mysql 索引的一些细节
前几天同事问了我个 mysql 索引的问题，虽然大概知道，但是还是想来实践下，就是 is null，is not null 这类查询是否能用索引，可能之前有些网上的文章说都是不能用索引，但是其实不是，我们来看个小试验
CREATE TABLE `null_index_t` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`null_key` varchar(255) DEFAULT NULL,
`null_key1` varchar(255) DEFAULT NULL,
diff --git a/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/index.html b/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/index.html
index 1f46b339d2..87956aeb52 100644
--- a/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/index.html
+++ b/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/index.html
@@ -1,4 +1,4 @@
-Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析 | Nicksxs's Blog 0%Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析
题目介绍
写一个程序找出两个单向链表的交叉起始点，可能是我英语不好，图里画的其实还有一点是交叉以后所有节点都是相同的
Write a program to find the node at which the intersection of two singly linked lists begins.
For example, the following two linked lists:
![]()
begin to intersect at node c1.
Example 1:
![]()
Input: intersectVal = 8, listA = [4,1,8,4,5], listB = [5,6,1,8,4,5], skipA = 2, skipB = 3
+Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析 | Nicksxs's Blog 0%Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析
题目介绍
写一个程序找出两个单向链表的交叉起始点，可能是我英语不好，图里画的其实还有一点是交叉以后所有节点都是相同的
Write a program to find the node at which the intersection of two singly linked lists begins.
For example, the following two linked lists:
![]()
begin to intersect at node c1.
Example 1:
![]()
Input: intersectVal = 8, listA = [4,1,8,4,5], listB = [5,6,1,8,4,5], skipA = 2, skipB = 3
Output: Reference of the node with value = 8
Input Explanation: The intersected node's value is 8 (note that this must not be 0 if the two lists intersect). From the head of A, it reads as [4,1,8,4,5]. From the head of B, it reads as [5,6,1,8,4,5]. There are 2 nodes before the intersected node in A; There are 3 nodes before the intersected node in B.
分析题解
一开始没什么头绪，感觉只能最原始的遍历，后来看了一些文章，发现比较简单的方式就是先找两个链表的长度差，因为从相交点开始肯定是长度一致的，这是个很好的解题突破口，找到长度差以后就是先跳过长链表的较长部分，然后开始同步遍历比较 A，B 链表；
代码
public ListNode getIntersectionNode(ListNode headA, ListNode headB) {
if (headA == null || headB == null) {
@@ -42,4 +42,4 @@ Input Explanation: The intersected node's value is 8 (note that this must no
}
}
return null;
- }
总结
可能缺少这种思维，做的还是比较少，所以没法一下子反应过来，需要锻炼，我的第一反应是两重遍历，不过那样复杂度就高了，这里应该是只有 O(N) 的复杂度。
总结
可能缺少这种思维，做的还是比较少，所以没法一下子反应过来，需要锻炼，我的第一反应是两重遍历，不过那样复杂度就高了，这里应该是只有 O(N) 的复杂度。
Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析 | Nicksxs's Blog 0%Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析
题目介绍
A path in a binary tree is a sequence of nodes where each pair of adjacent nodes in the sequence has an edge connecting them. A node can only appear in the sequence at most once. Note that the path does not need to pass through the root.
The path sum of a path is the sum of the node’s values in the path.
Given the root of a binary tree, return the maximum path sum of any path.
路径 被定义为一条从树中任意节点出发，沿父节点-子节点连接，达到任意节点的序列。该路径 至少包含一个 节点，且不一定经过根节点。
路径和 是路径中各节点值的总和。
给你一个二叉树的根节点 root ，返回其 最大路径和
简要分析
其实这个题目会被误解成比较简单，左子树最大的，或者右子树最大的，或者两边加一下，仔细想想都不对，其实有可能是产生于左子树中，或者右子树中，这两个都是指跟左子树根还有右子树根没关系的，这么说感觉不太容易理解，画个图
![]()
可以看到图里，其实最长路径和是左边这个子树组成的，跟根节点还有右子树完全没关系，然后再想一种情况，如果是整棵树就是图中的左子树，那么这个最长路径和就是左子树加右子树加根节点了，所以不是我一开始想得那么简单，在代码实现中也需要一些技巧
代码
int ansNew = Integer.MIN_VALUE;
+Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析 | Nicksxs's Blog 0%Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析
题目介绍
A path in a binary tree is a sequence of nodes where each pair of adjacent nodes in the sequence has an edge connecting them. A node can only appear in the sequence at most once. Note that the path does not need to pass through the root.
The path sum of a path is the sum of the node’s values in the path.
Given the root of a binary tree, return the maximum path sum of any path.
路径 被定义为一条从树中任意节点出发，沿父节点-子节点连接，达到任意节点的序列。该路径 至少包含一个 节点，且不一定经过根节点。
路径和 是路径中各节点值的总和。
给你一个二叉树的根节点 root ，返回其 最大路径和
简要分析
其实这个题目会被误解成比较简单，左子树最大的，或者右子树最大的，或者两边加一下，仔细想想都不对，其实有可能是产生于左子树中，或者右子树中，这两个都是指跟左子树根还有右子树根没关系的，这么说感觉不太容易理解，画个图
![]()
可以看到图里，其实最长路径和是左边这个子树组成的，跟根节点还有右子树完全没关系，然后再想一种情况，如果是整棵树就是图中的左子树，那么这个最长路径和就是左子树加右子树加根节点了，所以不是我一开始想得那么简单，在代码实现中也需要一些技巧
代码
int ansNew = Integer.MIN_VALUE;
public int maxPathSum(TreeNode root) {
maxSumNew(root);
return ansNew;
@@ -21,4 +21,4 @@
int res = Math.max(left + right + root.val, currentSum);
ans = Math.max(res, ans);
return currentSum;
-}
这里非常重要的就是 ansNew 是最后的一个结果，而对于 maxSumNew 这个函数的返回值其实是需要包含了一个连续结果，因为要返回继续去算路径和，所以返回的是 currentSum，最终结果是 ansNew
结果图
难得有个 100%，贴个图哈哈
![]()
这里非常重要的就是 ansNew 是最后的一个结果，而对于 maxSumNew 这个函数的返回值其实是需要包含了一个连续结果，因为要返回继续去算路径和，所以返回的是 currentSum，最终结果是 ansNew
结果图
难得有个 100%，贴个图哈哈
![]()
聊聊 Linux 下的 top 命令 | Nicksxs's Blog 0%聊聊 Linux 下的 top 命令
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H :Threads-mode operation
+聊聊 Linux 下的 top 命令 | Nicksxs's Blog 0%聊聊 Linux 下的 top 命令
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/2021/07/18/2021-年中总结/index.html b/2021/07/18/2021-年中总结/index.html
index be491b2dee..6b8ef4328a 100644
--- a/2021/07/18/2021-年中总结/index.html
+++ b/2021/07/18/2021-年中总结/index.html
@@ -1 +1 @@
-2021 年中总结 | Nicksxs's Blog 0%2021 年中总结 | Nicksxs's Blog 0%
链表应该是个需要反复的训练的数据结构，因为涉及到前后指针，然后更新操作，判空等，
我在这块也是掌握的不太好，需要多联系
链表应该是个需要反复的训练的数据结构，因为涉及到前后指针，然后更新操作，判空等，
我在这块也是掌握的不太好，需要多练习。
分类: gc | Nicksxs's Blog 0%分类: GC | Nicksxs's Blog 0%Nicksxs's Blog 0%2020 年终总结
拖更原因
这篇年终总结本来应该在农历过完年就出来的，结果是对没有受疫情影响的春节放假时间空闲情况预估太良好，虽然公司调了几天假，但是因为春节期间疫情状况比较好，本来酒店都不让接待聚餐什么的，后来统统放开，结果就是从初一到初六每天要不就是去亲戚家，要不就是去酒店饭店吃饭，计划很丰满，现实很骨感，时间感觉一下就没了，然后年后感觉有点犯懒了，所以才拖到现在。
生活-健身跑步
去年（19 年）的时候跑步突破了 300 公里，然后20 年给自己定了个 400 公里的目标，结果意料之中的没成功，原因可能疫情算一点吧，后面买了跑步机之后，基本周末回家都能跑一下，但是最后还是只跑了300 多公里，总的keep 记录跑量也没超过 1000 公里，所以跑步这个目标还是没成功的，不过还算是比去年多跑一点，这样也算后面好突破点，后面的目标就不定的太高了，每年能比前一年多一点就好，其实跑步已经从一种减肥方式变成一种习惯了，一周一次的跑步已经比较难有效减重了，但是对于保持精力和身体状态还是很有效和重要的，只是对于目前的体重还是要多减下去一些跑步才好，太重了对膝盖负担太大了，可惜还是时间呐，游泳骑车什么的都需要更苛刻的条件和时间，饮食呢控制起来比较难（贪吃
终于在 3 月底之前跑到了 1000 公里，迟了三个月，不过也总算达到了，只是体重控制还是不行，有试着走走楼梯，但是感觉对膝盖负担比较大，得再想想用什么方式
![]()
技术成长
一直提不起笔来写这篇年终总结还有个比较大的原因是觉得20 年的成长不如预期，大小目标都没怎么完成，比如深入了解 jvm，是想能有些深入的见解，而不再是某些点的比较片面的理解，系统性的归纳总结也比较少，每个方向或多或少有些看法和理解，但是不全面，一些东西看过了也会忘记，需要温故而知新，比如 AQS 的内容，第一次读其实理解比较浅，后面就强迫自己去读，去写，才有了一些比之前更深入的理解，因为很多文章都是带有作者思路的引导，适不适合自己都要看是否能从他的思路把它看懂，有些就差别很大，这个跟看书也一样，有些书大众一致推荐，一般情况下大多是经典的好的，但是也有可能是不太适合自己的，可能有时候机缘巧合看到的反而让人茅塞顿开，在 todo 里已经积攒了好多的点和面需要去学习实践，一方面是自己懒，一方面是时间也相对偏少，看看 21 年能不能有所提升，加强“时间管理”，哈哈
技术上主要是看了 mysql 的 mvcc 相关内容，rocketmq 的，redis 的代码，还有 mybatis 等，其实每一个都能写很多，也有很多值得学习的，需要全面系统学习，之前想好好画一个思维导图，将整个技术体系都梳理下，还只做了一点点，方式也有点问题，应该从大到小，而不是深度优先，细节有很多，每一个方面都有自己比较熟悉擅长的，也有不太了解的，可以做一个评分，这个也是亟待改善的，希望今年能完成。
博客
博客方面 20 年一年整是写了 53 篇，差不多是一周一篇的节奏，这个还是不错的，虽然博客质量参差不齐，但是这个更新频率还是比较好的，并且也定了个潜规则，可以一周技术一周生活，这样能缓解水文的频率，提高些技术文章的质量，虽然结果并没有好多少，不过感觉还是可以这么坚持的，能提高一些技术文章的质量那就更好了
聊聊 Linux 下的 top 命令
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H :Threads-mode operation
+Nicksxs's Blog 0%2020 年终总结
拖更原因
这篇年终总结本来应该在农历过完年就出来的，结果是对没有受疫情影响的春节放假时间空闲情况预估太良好，虽然公司调了几天假，但是因为春节期间疫情状况比较好，本来酒店都不让接待聚餐什么的，后来统统放开，结果就是从初一到初六每天要不就是去亲戚家，要不就是去酒店饭店吃饭，计划很丰满，现实很骨感，时间感觉一下就没了，然后年后感觉有点犯懒了，所以才拖到现在。
生活-健身跑步
去年（19 年）的时候跑步突破了 300 公里，然后20 年给自己定了个 400 公里的目标，结果意料之中的没成功，原因可能疫情算一点吧，后面买了跑步机之后，基本周末回家都能跑一下，但是最后还是只跑了300 多公里，总的keep 记录跑量也没超过 1000 公里，所以跑步这个目标还是没成功的，不过还算是比去年多跑一点，这样也算后面好突破点，后面的目标就不定的太高了，每年能比前一年多一点就好，其实跑步已经从一种减肥方式变成一种习惯了，一周一次的跑步已经比较难有效减重了，但是对于保持精力和身体状态还是很有效和重要的，只是对于目前的体重还是要多减下去一些跑步才好，太重了对膝盖负担太大了，可惜还是时间呐，游泳骑车什么的都需要更苛刻的条件和时间，饮食呢控制起来比较难（贪吃
终于在 3 月底之前跑到了 1000 公里，迟了三个月，不过也总算达到了，只是体重控制还是不行，有试着走走楼梯，但是感觉对膝盖负担比较大，得再想想用什么方式
![]()
技术成长
一直提不起笔来写这篇年终总结还有个比较大的原因是觉得20 年的成长不如预期，大小目标都没怎么完成，比如深入了解 jvm，是想能有些深入的见解，而不再是某些点的比较片面的理解，系统性的归纳总结也比较少，每个方向或多或少有些看法和理解，但是不全面，一些东西看过了也会忘记，需要温故而知新，比如 AQS 的内容，第一次读其实理解比较浅，后面就强迫自己去读，去写，才有了一些比之前更深入的理解，因为很多文章都是带有作者思路的引导，适不适合自己都要看是否能从他的思路把它看懂，有些就差别很大，这个跟看书也一样，有些书大众一致推荐，一般情况下大多是经典的好的，但是也有可能是不太适合自己的，可能有时候机缘巧合看到的反而让人茅塞顿开，在 todo 里已经积攒了好多的点和面需要去学习实践，一方面是自己懒，一方面是时间也相对偏少，看看 21 年能不能有所提升，加强“时间管理”，哈哈
技术上主要是看了 mysql 的 mvcc 相关内容，rocketmq 的，redis 的代码，还有 mybatis 等，其实每一个都能写很多，也有很多值得学习的，需要全面系统学习，之前想好好画一个思维导图，将整个技术体系都梳理下，还只做了一点点，方式也有点问题，应该从大到小，而不是深度优先，细节有很多，每一个方面都有自己比较熟悉擅长的，也有不太了解的，可以做一个评分，这个也是亟待改善的，希望今年能完成。
博客
博客方面 20 年一年整是写了 53 篇，差不多是一周一篇的节奏，这个还是不错的，虽然博客质量参差不齐，但是这个更新频率还是比较好的，并且也定了个潜规则，可以一周技术一周生活，这样能缓解水文的频率，提高些技术文章的质量，虽然结果并没有好多少，不过感觉还是可以这么坚持的，能提高一些技术文章的质量那就更好了
聊聊 Linux 下的 top 命令
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/14/index.html b/page/14/index.html
index f04ca7f97b..8cc30f8d5d 100644
--- a/page/14/index.html
+++ b/page/14/index.html
@@ -87,7 +87,7 @@ Input Explanation: The intersected node's value is 8 (note that this must no
}
}
return false;
- }
然后呢就是为啥一些书或者 effective java 中写了 equals 跟 hashCode 要一起重写，这里涉及到当对象作为 HashMap 的 key 的时候
首先 HashMap 会使用 hashCode 去判断是否在同一个槽里，然后在通过 equals 去判断是否是同一个 key，是的话就替换，不是的话就链表接下去，如果不重写 hashCode 的话，默认的 object 的hashCode 是 native 方法，根据对象的地址生成的，这样其实对象的值相同的话，因为地址不同，HashMap 也会出现异常，所以需要重写，同时也需要重写 equals 方法，才能确认是同一个 key，而不是落在同一个槽的不同 key.
聊聊 mysql 索引的一些细节
前几天同事问了我个 mysql 索引的问题，虽然大概知道，但是还是想来实践下，就是 is null，is not null 这类查询是否能用索引，可能之前有些网上的文章说都是不能用索引，但是其实不是，我们来看个小试验
CREATE TABLE `null_index_t` (
+ }
然后呢就是为啥一些书或者 effective java 中写了 equals 跟 hashCode 要一起重写，这里涉及到当对象作为 HashMap 的 key 的时候
首先 HashMap 会使用 hashCode 去判断是否在同一个槽里，然后在通过 equals 去判断是否是同一个 key，是的话就替换，不是的话就链表接下去，如果不重写 hashCode 的话，默认的 object 的hashCode 是 native 方法，根据对象的地址生成的，这样其实对象的值相同的话，因为地址不同，HashMap 也会出现异常，所以需要重写，同时也需要重写 equals 方法，才能确认是同一个 key，而不是落在同一个槽的不同 key.
聊聊 mysql 索引的一些细节
前几天同事问了我个 mysql 索引的问题，虽然大概知道，但是还是想来实践下，就是 is null，is not null 这类查询是否能用索引，可能之前有些网上的文章说都是不能用索引，但是其实不是，我们来看个小试验
CREATE TABLE `null_index_t` (
`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`null_key` varchar(255) DEFAULT NULL,
`null_key1` varchar(255) DEFAULT NULL,
diff --git a/page/17/index.html b/page/17/index.html
index 47f9c336d3..90760d8358 100644
--- a/page/17/index.html
+++ b/page/17/index.html
@@ -30,7 +30,7 @@ Output: [8,9,9,9,0,0,0,1]
// tail = null;
return root;
- }
这里唯二需要注意的就是两个点，一个是循环条件需要包含进位值还存在的情况，还有一个是最后一个节点，如果是空的了，就不要在 new 一个出来了，写的比较挫
mybatis 的缓存是怎么回事
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 一个出来了，写的比较挫
mybatis 的缓存是怎么回事
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 a92234f474..becd23d72c 100644
--- a/page/18/index.html
+++ b/page/18/index.html
@@ -1,4 +1,4 @@
-Nicksxs's Blog 0%mybatis 的 $ 和 # 是有啥区别
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条select * from t1 where id = #{id}这样的 sql，在初始化扫描 mapper 的xml文件的时候会根据是否是 dynamic 来判断生成 DynamicSqlSource 还是 RawSqlSource，这里它是一条 RawSqlSource，
在这里做了替换，将#{}替换成了?
![]()
前面说的是否 dynamic 就是在这里进行判断
![]()
// org.apache.ibatis.scripting.xmltags.XMLScriptBuilder#parseScriptNode
+Nicksxs's Blog 0%mybatis 的 $ 和 # 是有啥区别
这个问题也是面试中常被问到的，就抽空来了解下这个，跳过一大段前面初始化的逻辑，
对于一条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;
@@ -499,7 +499,7 @@ public class DynamicSqlSource implements SqlSource {
public String hello() {
return "hello world";
}
-}
好了，请求一下，看看 stdout，
![]()
搞定完事儿~
周末我在老丈人家打了天小工
这周回家提前约好了要去老丈人家帮下忙，因为在翻修下老房子，活不是特别整的那种，所以大部分都是自己干，或者找个大工临时干几天（我们这那种比较专业的泥工匠叫做大工），像我这样去帮忙的，就是干点小工（把给大工帮忙的，干些偏体力活的叫做小工）的活。从大学毕业以后真的蛮少帮家里干活了，以前上学的时候放假还是帮家里淘个米，简单的扫地拖地啥的，当然刚高考完的时候，还去我爸厂里帮忙干了几天的活，实在是比较累，不过现在想着是觉得自己那时候比较牛，而不是特别排斥这个活，相对于现在的工作来说，导致了一系列的职业病，颈椎腰背都很僵硬，眼镜也不好，还有反流，像我爸那种活反而是脑力加体力的比较好的结合。
这一天的活前半部分主要是在清理厨房，瓷砖上的油污和墙上天花板上即将脱落的石灰或者白色涂料层，这种活特别是瓷砖上的油污，之前在自己家里也干活，还是比较熟悉的，不过前面主要是LD 在干，我主要是先搞墙上和天花板上的，干活还是很需要技巧的，如果直接去铲，那基本我会变成一个灰人，而且吸一鼻子灰，老丈人比较专业，先接上软管用水冲，一冲效果特别好，有些石灰涂料层直接就冲掉了，冲完之后先用带加长杆的刀片铲铲了一圈墙面，说实话因为老房子之前租出去了，所以墙面什么的被糟蹋的比较难看，一层一层的，不过这还算还好，后面主要是天花板上的，这可难倒我了，从小我爸妈是比较把我当小孩管着，爬上爬下的基本都是我爸搞定，但是到了老丈人家也只得硬着头皮上了，爬到跳（一种建筑工地用的架子）上，还有点晃，小心脏扑通扑通跳，而且带加长杆的铲子还是比较重的，铲一会手也有点累，不过坚持着铲完了，上面还是比较平整的，不过下来的时候又把我难住了🤦♂️，往下爬的时候有根杆子要跨过去，由于裤子比较紧，强行一把跨过去怕抽筋，所以以一个非常尴尬的姿势停留休息了一会，再跨了过去，幸好事后问 LD，他们都没看到，哈哈哈，然后就是帮忙一起搞瓷砖上的油污，这个太有经验了，不过老丈人更有意思，一会试试啤酒，一会用用沙子，后面在午饭前基本就弄的比较干净了，就坐着等吃饭了，下午午休了会，就继续干活了。
下午是我这次体验的重点了，因为要清理以前贴的墙纸，真的是个很麻烦的活，只能说贴墙纸的师傅活干得太好了，基本不可能整个撕下来，想用铲子一点点铲下来也不行，太轻了就只铲掉表面一层，太重了就把墙纸跟墙面的石灰啥的整个铲下来了，而且手又累又酸，后来想着是不是继续用水冲一下，对着一小面墙试验了下，效果还不错，但是又发现了个问题，那一面墙又有一块是后面糊上去的，铲掉外层的石灰后不平，然后就是最最重头的，也是让我后遗症持续到第二天的，要把那一块糊上去的水泥敲下来，毛估下大概是敲了80%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。
Linux 下 grep 命令的一点小技巧
用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，
譬如
+}
好了，请求一下，看看 stdout，
![]()
搞定完事儿~
周末我在老丈人家打了天小工
这周回家提前约好了要去老丈人家帮下忙，因为在翻修下老房子，活不是特别整的那种，所以大部分都是自己干，或者找个大工临时干几天（我们这那种比较专业的泥工匠叫做大工），像我这样去帮忙的，就是干点小工（把给大工帮忙的，干些偏体力活的叫做小工）的活。从大学毕业以后真的蛮少帮家里干活了，以前上学的时候放假还是帮家里淘个米，简单的扫地拖地啥的，当然刚高考完的时候，还去我爸厂里帮忙干了几天的活，实在是比较累，不过现在想着是觉得自己那时候比较牛，而不是特别排斥这个活，相对于现在的工作来说，导致了一系列的职业病，颈椎腰背都很僵硬，眼镜也不好，还有反流，像我爸那种活反而是脑力加体力的比较好的结合。
这一天的活前半部分主要是在清理厨房，瓷砖上的油污和墙上天花板上即将脱落的石灰或者白色涂料层，这种活特别是瓷砖上的油污，之前在自己家里也干活，还是比较熟悉的，不过前面主要是LD 在干，我主要是先搞墙上和天花板上的，干活还是很需要技巧的，如果直接去铲，那基本我会变成一个灰人，而且吸一鼻子灰，老丈人比较专业，先接上软管用水冲，一冲效果特别好，有些石灰涂料层直接就冲掉了，冲完之后先用带加长杆的刀片铲铲了一圈墙面，说实话因为老房子之前租出去了，所以墙面什么的被糟蹋的比较难看，一层一层的，不过这还算还好，后面主要是天花板上的，这可难倒我了，从小我爸妈是比较把我当小孩管着，爬上爬下的基本都是我爸搞定，但是到了老丈人家也只得硬着头皮上了，爬到跳（一种建筑工地用的架子）上，还有点晃，小心脏扑通扑通跳，而且带加长杆的铲子还是比较重的，铲一会手也有点累，不过坚持着铲完了，上面还是比较平整的，不过下来的时候又把我难住了🤦♂️，往下爬的时候有根杆子要跨过去，由于裤子比较紧，强行一把跨过去怕抽筋，所以以一个非常尴尬的姿势停留休息了一会，再跨了过去，幸好事后问 LD，他们都没看到，哈哈哈，然后就是帮忙一起搞瓷砖上的油污，这个太有经验了，不过老丈人更有意思，一会试试啤酒，一会用用沙子，后面在午饭前基本就弄的比较干净了，就坐着等吃饭了，下午午休了会，就继续干活了。
下午是我这次体验的重点了，因为要清理以前贴的墙纸，真的是个很麻烦的活，只能说贴墙纸的师傅活干得太好了，基本不可能整个撕下来，想用铲子一点点铲下来也不行，太轻了就只铲掉表面一层，太重了就把墙纸跟墙面的石灰啥的整个铲下来了，而且手又累又酸，后来想着是不是继续用水冲一下，对着一小面墙试验了下，效果还不错，但是又发现了个问题，那一面墙又有一块是后面糊上去的，铲掉外层的石灰后不平，然后就是最最重头的，也是让我后遗症持续到第二天的，要把那一块糊上去的水泥敲下来，毛估下大概是敲了80%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。
Linux 下 grep 命令的一点小技巧
用了比较久的 grep 命令，其实都只是用了最最基本的功能来查日志，
譬如
grep 'xxx' xxxx.log
然后有挺多情况比如想要找日志里带一些符号什么的，就需要用到一些特殊的
比如这样\"userId\":\"123456\"，因为比如用户 ID 有时候会跟其他的 id 一样，只用具体的值 123456 来查的话干扰信息太多了，如果直接这样
grep '\"userId\":\"123456\"' xxxx.log
diff --git a/page/21/index.html b/page/21/index.html
index d0735aa803..2e2bedc899 100644
--- a/page/21/index.html
+++ b/page/21/index.html
@@ -4,7 +4,7 @@
at TreeDistance.treeDist(TreeDistance.java:65)
at TreeDistance.treeDist(TreeDistance.java:65)
at TreeDistance.treeDist(TreeDistance.java:65)
- at TreeDistance.main(TreeDistance.java:45)
这就是我们主线程的堆栈信息了，main 表示这个线程名，prio表示优先级，默认是 5，tid 表示线程 id，nid 表示对应的系统线程，后面的runnable 表示目前线程状态，因为是被我打了断点，所以是就许状态，然后下面就是对应的线程栈内容了，在TreeDistance类的 treeDist方法中，对应的文件行数是 64 行。
这里使用 thread dump一般也不会是上面我截图代码里的这种代码量很少的，一般是大型项目，有时候跑着跑着没反应，又不知道跑到哪了，特别是一些刚接触的大项目或者需要定位一个大项目的一个疑难问题，一时没思路时，可以使用这个方法，个人觉得非常有帮助。
聊聊我理解的分布式事务
前面说了mysql数据库的事务相关的，那事务是用来干嘛的，这里得补一下ACID，
ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。
Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。[1]
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。[1]
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read uncommitted）、提交读（read committed）、可重复读（repeatable read）和串行化（Serializable）。[1]
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。[1]
在mysql中，借助于MVCC，各种级别的锁，日志等特性来实现了事务的ACID，但是这个我们通常是对于一个数据库服务的定义，常见的情况下我们的数据库随着业务发展也会从单实例变成多实例，组成主从Master-Slave架构，这个时候其实会有一些问题随之出现，比如说主从同步延迟，假如在业务代码中做了读写分离，对于一些敏感度较低的数据其实问题不是很大，只要主从延迟不到特别夸张的地步一般都是可以忍受的，但是对于一些核心的业务数据，比如订单之类的，不能忍受数据不一致，下了单了，付了款了，一刷订单列表，发现这个订单还没支付，甚至订单都没在，这对于用户来讲是恨不能容忍的错误，那么这里就需要一些措施，要不就不读写分离，要不就在 redis 这类缓存下订单，或者支付后加个延时等，这些都是一些补偿措施，并且这也是一个不太切当的例子，比较合适的例子也可以用这个下单来说，一般在电商平台下单会有挺多要做的事情，比如像下面这个图
![]()
下单的是后要冻结核销优惠券，如果账户里有钱要冻结扣除账户里的钱，如果使用了J 豆也一样，可能还有 E 卡，忽略我借用的平台，因为目前一般后台服务化之后，可能每一项都是对应的一个后台服务，我们期望的执行过程是要不全成功，要不就全保持执行前状态，不能是部分扣减核销成功了，部分还不行，所以我们处理这种情况会引入一些通用的方案，第一种叫二阶段提交,
二阶段提交（英语：Two-phase Commit）是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议（Protocol）。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新后的数据写入磁盘等等）。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
对于上面的例子，我们将整个过程分成两个阶段，首先是提交请求阶段，这个阶段大概需要做的是确定资源存在，锁定资源，可能还要做好失败后回滚的准备，如果这些都 ok 了那么就响应成功，这里其实用到了一个叫事务的协调者的角色，类似于裁判员，每个节点都反馈第一阶段成功后，开始执行第二阶段，也就是实际执行操作，这里也是需要所有节点都反馈成功后才是执行成功，要不就是失败回滚。其实常用的分布式事务的解决方案主要也是基于此方案的改进，比如后面介绍的三阶段提交，有三阶段提交就是因为二阶段提交比较尴尬的几个点，
- 第一是对于两阶段提交，其中默认只有协调者有超时时间，当一个参与者进入卡死状态时只能依赖协调者的超时来结束任务，这中间的时间参与者都是锁定着资源
- 第二是协调者的单点问题，万一挂了，参与者就会在那傻等着
所以三阶段提交引入了各节点的超时机制和一个准备阶段，首先是一个can commit阶段，询问下各个节点有没有资源，能不能进行操作，这个阶段不阻塞，只是提前做个摸底，这个阶段其实人畜无害，但是能提高成功率，在这个阶段如果就有节点反馈是不接受的，那就不用执行下去了，也没有锁资源，然后第二阶段是 pre commit ，这个阶段做的事情跟原来的 第一阶段比较类似，然后是第三阶段do commit，其实三阶段提交我个人觉得只是加了个超时，和准备阶段，好像木有根本性的解决的两阶段提交的问题，后续可以再看看一些论文来思考讨论下。
2020年05月24日22:11 更新
这里跟朋友讨论了下，好像想通了最核心的一点，对于前面说的那个场景，如果是两阶段提交，如果各个节点中有一个没回应，并且协调者也挂了，这个时候会有什么情况呢，再加一个假设，其实比如这个一阶段其实是检验就失败的，理论上应该大家都释放资源，那么对于这种异常情况，其他的参与者就不知所措了，就傻傻地锁着资源阻塞着，那么三阶段提交的意义就出现了，把第一阶段拆开，那么即使在这个阶段出现上述的异常，即也不会锁定资源，同时参与者也有超时机制，在第二阶段锁定资源出现异常是，其他参与者节点等超时后就自动释放资源了，也就没啥问题了，不过对于那种异常恢复后的一些情况还是没有很好地解决，需要借助 zk 等，后面有空可以讲讲 paxos 跟 raft 等
聊聊 mysql 的 MVCC 续续篇之锁分析
看完前面两篇水文之后，感觉不得不来分析下 mysql 的锁了，其实前面说到幻读的时候是有个前提没提到的，比如一个select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的，当然这里是指在 RR 或者 RC 隔离级别下，
看一段 mysql官方文档
SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
纯粹的这种一致性读，实际读取的是快照，也就是基于 read view 的读取方式，除非当前隔离级别是SERIALIZABLE
但是对于以下几类
select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;
除了第一条是 S 锁之外，其他都是 X 排他锁，这边在顺带下，S 锁表示共享锁， X 表示独占锁，同为 S 锁之间不冲突，S 与 X，X 与 S，X 与 X 之间都冲突，也就是加了前者，后者就加不上了
我们知道对于 RC 级别会出现幻读现象，对于 RR 级别不会出现，主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁，那么是不是 RR 级别下以上所有的都是要加 gap 锁呢，当然不是
举个例子，RR 事务隔离级别下，table1 有个主键id 字段
select * from table1 where id = 10 for update
这条语句要加 gap 锁吗？
答案是不需要，这里其实算是我看了这么久的一点自己的理解，啥时候要加 gap 锁，判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致，我上面这条查询语句，在什么情况下会出现查询结果数量不一致呢，只要在这条记录被更新或者删除的时候，有没有可能我第一次查出来一条，第二次变成两条了呢，不可能，因为是主键索引。
再变更下这个题的条件，当 id 不是主键，但是是唯一索引，这样需要怎么加锁，注意问题是怎么加锁，不是需不需要加 gap 锁，这里呢就是稍微延伸一下，把聚簇索引（主键索引）和二级索引带一下，当 id 不是主键，说明是个二级索引，但是它是唯一索引，体会下，首先对于 id = 10这个二级索引肯定要加锁，要不要锁 gap 呢，不用，因为是唯一索引，id = 10 只可能有这一条记录，然后呢，这样是不是就好了，还不行，因为啥，因为它是二级索引，对应的主键索引的记录才是真正的数据，万一被更新掉了咋办，所以在 id = 10 对应的主键索引上也需要加上锁（默认都是 record lock行锁），那主键索引上要不要加 gap 呢，也不用，也是精确定位到这一条记录
最后呢，当 id 不是主键，也不是唯一索引，只是个普通的索引，这里就需要大名鼎鼎的 gap 锁了，
是时候画个图了
![]()
其实核心的目的还是不让这个 id=10 的记录不会出现幻读，那么就需要在 id 这个索引上加上三个 gap 锁，主键索引上就不用了，在 id 索引上已经控制住了id = 10 不会出现幻读，主键索引上这两条对应的记录已经锁了，所以就这样 OK 了
聊聊 mysql 的 MVCC 续篇
上一篇聊了mysql 的 innodb 引擎基于 read view 实现的 mvcc 和事务隔离级别，可能有些细心的小伙伴会发现一些问题，第一个是在 RC 级别下的事务提交后的可见性，这里涉及到了三个参数，m_low_limit_id，m_up_limit_id，m_ids，之前看到知乎的一篇写的非常不错的文章，但是就在这一点上似乎有点疑惑，这里基于源码和注释来解释下这个问题
/**
+ at TreeDistance.main(TreeDistance.java:45)
这就是我们主线程的堆栈信息了，main 表示这个线程名，prio表示优先级，默认是 5，tid 表示线程 id，nid 表示对应的系统线程，后面的runnable 表示目前线程状态，因为是被我打了断点，所以是就许状态，然后下面就是对应的线程栈内容了，在TreeDistance类的 treeDist方法中，对应的文件行数是 64 行。
这里使用 thread dump一般也不会是上面我截图代码里的这种代码量很少的，一般是大型项目，有时候跑着跑着没反应，又不知道跑到哪了，特别是一些刚接触的大项目或者需要定位一个大项目的一个疑难问题，一时没思路时，可以使用这个方法，个人觉得非常有帮助。
聊聊我理解的分布式事务
前面说了mysql数据库的事务相关的，那事务是用来干嘛的，这里得补一下ACID，
ACID，是指数据库管理系统（DBMS）在写入或更新资料的过程中，为保证事务（transaction）是正确可靠的，所必须具备的四个特性：原子性（atomicity，或称不可分割性）、一致性（consistency）、隔离性（isolation，又称独立性）、持久性（durability）。
Atomicity（原子性）：一个事务（transaction）中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。即，事务不可分割、不可约简。[1]
Consistency（一致性）：在事务开始之前和事务结束以后，数据库的完整性没有被破坏。这表示写入的资料必须完全符合所有的预设约束、触发器、级联回滚等。[1]
Isolation（隔离性）：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。事务隔离分为不同级别，包括未提交读（Read uncommitted）、提交读（read committed）、可重复读（repeatable read）和串行化（Serializable）。[1]
Durability（持久性）：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。[1]
在mysql中，借助于MVCC，各种级别的锁，日志等特性来实现了事务的ACID，但是这个我们通常是对于一个数据库服务的定义，常见的情况下我们的数据库随着业务发展也会从单实例变成多实例，组成主从Master-Slave架构，这个时候其实会有一些问题随之出现，比如说主从同步延迟，假如在业务代码中做了读写分离，对于一些敏感度较低的数据其实问题不是很大，只要主从延迟不到特别夸张的地步一般都是可以忍受的，但是对于一些核心的业务数据，比如订单之类的，不能忍受数据不一致，下了单了，付了款了，一刷订单列表，发现这个订单还没支付，甚至订单都没在，这对于用户来讲是恨不能容忍的错误，那么这里就需要一些措施，要不就不读写分离，要不就在 redis 这类缓存下订单，或者支付后加个延时等，这些都是一些补偿措施，并且这也是一个不太切当的例子，比较合适的例子也可以用这个下单来说，一般在电商平台下单会有挺多要做的事情，比如像下面这个图
![]()
下单的是后要冻结核销优惠券，如果账户里有钱要冻结扣除账户里的钱，如果使用了J 豆也一样，可能还有 E 卡，忽略我借用的平台，因为目前一般后台服务化之后，可能每一项都是对应的一个后台服务，我们期望的执行过程是要不全成功，要不就全保持执行前状态，不能是部分扣减核销成功了，部分还不行，所以我们处理这种情况会引入一些通用的方案，第一种叫二阶段提交,
二阶段提交（英语：Two-phase Commit）是指在计算机网络以及数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种算法。通常，二阶段提交也被称为是一种协议（Protocol）。在分布式系统中，每个节点虽然可以知晓自己的操作时成功或者失败，却无法知道其他节点的操作的成功或失败。当一个事务跨越多个节点时，为了保持事务的ACID特性，需要引入一个作为协调者的组件来统一掌控所有节点（称作参与者）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交（比如将更新后的数据写入磁盘等等）。因此，二阶段提交的算法思路可以概括为： 参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作。
对于上面的例子，我们将整个过程分成两个阶段，首先是提交请求阶段，这个阶段大概需要做的是确定资源存在，锁定资源，可能还要做好失败后回滚的准备，如果这些都 ok 了那么就响应成功，这里其实用到了一个叫事务的协调者的角色，类似于裁判员，每个节点都反馈第一阶段成功后，开始执行第二阶段，也就是实际执行操作，这里也是需要所有节点都反馈成功后才是执行成功，要不就是失败回滚。其实常用的分布式事务的解决方案主要也是基于此方案的改进，比如后面介绍的三阶段提交，有三阶段提交就是因为二阶段提交比较尴尬的几个点，
- 第一是对于两阶段提交，其中默认只有协调者有超时时间，当一个参与者进入卡死状态时只能依赖协调者的超时来结束任务，这中间的时间参与者都是锁定着资源
- 第二是协调者的单点问题，万一挂了，参与者就会在那傻等着
所以三阶段提交引入了各节点的超时机制和一个准备阶段，首先是一个can commit阶段，询问下各个节点有没有资源，能不能进行操作，这个阶段不阻塞，只是提前做个摸底，这个阶段其实人畜无害，但是能提高成功率，在这个阶段如果就有节点反馈是不接受的，那就不用执行下去了，也没有锁资源，然后第二阶段是 pre commit ，这个阶段做的事情跟原来的 第一阶段比较类似，然后是第三阶段do commit，其实三阶段提交我个人觉得只是加了个超时，和准备阶段，好像木有根本性的解决的两阶段提交的问题，后续可以再看看一些论文来思考讨论下。
2020年05月24日22:11 更新
这里跟朋友讨论了下，好像想通了最核心的一点，对于前面说的那个场景，如果是两阶段提交，如果各个节点中有一个没回应，并且协调者也挂了，这个时候会有什么情况呢，再加一个假设，其实比如这个一阶段其实是检验就失败的，理论上应该大家都释放资源，那么对于这种异常情况，其他的参与者就不知所措了，就傻傻地锁着资源阻塞着，那么三阶段提交的意义就出现了，把第一阶段拆开，那么即使在这个阶段出现上述的异常，即也不会锁定资源，同时参与者也有超时机制，在第二阶段锁定资源出现异常是，其他参与者节点等超时后就自动释放资源了，也就没啥问题了，不过对于那种异常恢复后的一些情况还是没有很好地解决，需要借助 zk 等，后面有空可以讲讲 paxos 跟 raft 等
聊聊 mysql 的 MVCC 续续篇之锁分析
看完前面两篇水文之后，感觉不得不来分析下 mysql 的锁了，其实前面说到幻读的时候是有个前提没提到的，比如一个select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的，当然这里是指在 RR 或者 RC 隔离级别下，
看一段 mysql官方文档
SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
纯粹的这种一致性读，实际读取的是快照，也就是基于 read view 的读取方式，除非当前隔离级别是SERIALIZABLE
但是对于以下几类
select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;
除了第一条是 S 锁之外，其他都是 X 排他锁，这边在顺带下，S 锁表示共享锁， X 表示独占锁，同为 S 锁之间不冲突，S 与 X，X 与 S，X 与 X 之间都冲突，也就是加了前者，后者就加不上了
我们知道对于 RC 级别会出现幻读现象，对于 RR 级别不会出现，主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁，那么是不是 RR 级别下以上所有的都是要加 gap 锁呢，当然不是
举个例子，RR 事务隔离级别下，table1 有个主键id 字段
select * from table1 where id = 10 for update
这条语句要加 gap 锁吗？
答案是不需要，这里其实算是我看了这么久的一点自己的理解，啥时候要加 gap 锁，判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致，我上面这条查询语句，在什么情况下会出现查询结果数量不一致呢，只要在这条记录被更新或者删除的时候，有没有可能我第一次查出来一条，第二次变成两条了呢，不可能，因为是主键索引。
再变更下这个题的条件，当 id 不是主键，但是是唯一索引，这样需要怎么加锁，注意问题是怎么加锁，不是需不需要加 gap 锁，这里呢就是稍微延伸一下，把聚簇索引（主键索引）和二级索引带一下，当 id 不是主键，说明是个二级索引，但是它是唯一索引，体会下，首先对于 id = 10这个二级索引肯定要加锁，要不要锁 gap 呢，不用，因为是唯一索引，id = 10 只可能有这一条记录，然后呢，这样是不是就好了，还不行，因为啥，因为它是二级索引，对应的主键索引的记录才是真正的数据，万一被更新掉了咋办，所以在 id = 10 对应的主键索引上也需要加上锁（默认都是 record lock行锁），那主键索引上要不要加 gap 呢，也不用，也是精确定位到这一条记录
最后呢，当 id 不是主键，也不是唯一索引，只是个普通的索引，这里就需要大名鼎鼎的 gap 锁了，
是时候画个图了
![]()
其实核心的目的还是不让这个 id=10 的记录不会出现幻读，那么就需要在 id 这个索引上加上三个 gap 锁，主键索引上就不用了，在 id 索引上已经控制住了id = 10 不会出现幻读，主键索引上这两条对应的记录已经锁了，所以就这样 OK 了
聊聊 mysql 的 MVCC 续篇
上一篇聊了mysql 的 innodb 引擎基于 read view 实现的 mvcc 和事务隔离级别，可能有些细心的小伙伴会发现一些问题，第一个是在 RC 级别下的事务提交后的可见性，这里涉及到了三个参数，m_low_limit_id，m_up_limit_id，m_ids，之前看到知乎的一篇写的非常不错的文章，但是就在这一点上似乎有点疑惑，这里基于源码和注释来解释下这个问题
/**
Opens a read view where exactly the transactions serialized before this
point in time are seen in the view.
@param id Creator transaction id */
@@ -14,7 +14,7 @@ void ReadView::prepare(trx_id_t id) {
m_creator_trx_id = id;
- m_low_limit_no = m_low_limit_id = m_up_limit_id = trx_sys->max_trx_id;
m_low_limit_id赋的值是trx_sys->max_trx_id，代表的是当前系统最小的未分配的事务 id，所以呢，举个例子，当前有三个活跃事务，事务 id 分别是 100，200，300，而 m_up_limit_id = 100, m_low_limit_id = 301，当事务 id 是 200 的提交之后，它的更新就是可以被 100 和 300 看到，而不是说 m_ids 里没了 200，并且 200 比 100 大就应该不可见了
幻读
还有一个问题是幻读的问题，这貌似也是个高频面试题，啥意思呢，或者说跟它最常拿来比较的脏读，脏读是指读到了别的事务未提交的数据，因为未提交，严格意义上来讲，不一定是会被最后落到库里，可能会回滚，也就是在 read uncommitted 级别下会出现的问题，但是幻读不太一样，幻读是指两次查询的结果数量不一样，比如我查了第一次是 select * from table1 where id < 10 for update,查出来了一条结果 id 是 5，然后再查一下发现出来了一条 id 是 5，一条 id 是 7，那是不是有点尴尬了，其实呢这个点我觉得脏读跟幻读也比较是从原理层面来命名，如果第一次接触的同学发觉有点不理解也比较正常，因为从逻辑上讲总之都是数据不符合预期，但是基于源码层面其实是不同的情况，幻读是在原先的 read view 无法完全解决的，怎么解决呢，简单的来说就是锁咯，我们知道innodb 是基于 record lock 行锁的，但是貌似没有办法解决这种问题，那么 innodb 就引入了 gap lock 间隙锁，比如上面说的情况下，id 小于 10 的情况下，是都应该锁住的，gap lock 其实是基于索引结构来锁的，因为索引树除了树形结构之外，还有一个next record 的指针，gap lock 也是基于这个来锁的
看一下 mysql 的文档
SELECT … FOR UPDATE sets an exclusive next-key lock on every record the search encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
对于一个 for update 查询，在 RR 级别下，会设置一个 next-key lock在每一条被查询到的记录上，next-lock 又是啥呢，其实就是 gap 锁和 record 锁的结合体，比如我在数据库里有 id 是 1，3，5，7，10，对于上面那条查询，查出来的结果就是 1，3，5，7，那么按照文档里描述的，对于这几条记录都会加上next-key lock，也就是(-∞, 1], (1, 3], (3, 5], (5, 7], (7, 10) 这些区间和记录会被锁起来，不让插入，再唠叨一下呢，就是其实如果是只读的事务，光 read view 一致性读就够了，如果是有写操作的呢，就需要锁了。
聊聊 mysql 的 MVCC
很久以前，有位面试官问到，你知道 mysql 的事务隔离级别吗，“额 O__O …，不太清楚”，完了之后我就去网上找相关的文章，找到了这篇MySQL 四种事务隔离级的说明, 文章写得特别好，看了这个就懂了各个事务隔离级别都是啥，不过看了这个之后多思考一下的话还是会发现问题，这么神奇的事务隔离级别是怎么实现的呢
其中 innodb 的事务隔离用到了标题里说到的 mvcc，Multiversion concurrency control, 直译过来就是多版本并发控制，先不讲这个究竟是个啥，考虑下如果纯猜测，这个事务隔离级别应该会是怎么样实现呢，愚钝的我想了下，可以在事务开始的时候拷贝一个表，这个可以支持 RR 级别，RC 级别就不支持了，而且要是个非常大的表，想想就不可行
腆着脸说虽然这个不可行，但是思路是对的，具体实行起来需要做一系列（肥肠多）的改动，首先根据我的理解，其实这个拷贝一个表是变成拷贝一条记录，但是如果有多个事务，那就得拷贝多次，这个问题其实可以借助版本管理系统来解释，在用版本管理系统，git 之类的之前，很原始的可能是开发完一个功能后，就打个压缩包用时间等信息命名，然后如果后面要找回这个就直接用这个压缩包的就行了，后来有了 svn，git 中心式和分布式的版本管理系统，它的一个特点是粒度可以控制到文件和代码行级别，对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别，可能之前很多人都了解过，数据库的一行记录除了我们用户自定义的字段，还有一些额外的字段，去源码data0type.h里捞一下
/* Precise data types for system columns and the length of those columns;
+ m_low_limit_no = m_low_limit_id = m_up_limit_id = trx_sys->max_trx_id;
m_low_limit_id赋的值是trx_sys->max_trx_id，代表的是当前系统最小的未分配的事务 id，所以呢，举个例子，当前有三个活跃事务，事务 id 分别是 100，200，300，而 m_up_limit_id = 100, m_low_limit_id = 301，当事务 id 是 200 的提交之后，它的更新就是可以被 100 和 300 看到，而不是说 m_ids 里没了 200，并且 200 比 100 大就应该不可见了
幻读
还有一个问题是幻读的问题，这貌似也是个高频面试题，啥意思呢，或者说跟它最常拿来比较的脏读，脏读是指读到了别的事务未提交的数据，因为未提交，严格意义上来讲，不一定是会被最后落到库里，可能会回滚，也就是在 read uncommitted 级别下会出现的问题，但是幻读不太一样，幻读是指两次查询的结果数量不一样，比如我查了第一次是 select * from table1 where id < 10 for update,查出来了一条结果 id 是 5，然后再查一下发现出来了一条 id 是 5，一条 id 是 7，那是不是有点尴尬了，其实呢这个点我觉得脏读跟幻读也比较是从原理层面来命名，如果第一次接触的同学发觉有点不理解也比较正常，因为从逻辑上讲总之都是数据不符合预期，但是基于源码层面其实是不同的情况，幻读是在原先的 read view 无法完全解决的，怎么解决呢，简单的来说就是锁咯，我们知道innodb 是基于 record lock 行锁的，但是貌似没有办法解决这种问题，那么 innodb 就引入了 gap lock 间隙锁，比如上面说的情况下，id 小于 10 的情况下，是都应该锁住的，gap lock 其实是基于索引结构来锁的，因为索引树除了树形结构之外，还有一个next record 的指针，gap lock 也是基于这个来锁的
看一下 mysql 的文档
SELECT … FOR UPDATE sets an exclusive next-key lock on every record the search encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
对于一个 for update 查询，在 RR 级别下，会设置一个 next-key lock在每一条被查询到的记录上，next-lock 又是啥呢，其实就是 gap 锁和 record 锁的结合体，比如我在数据库里有 id 是 1，3，5，7，10，对于上面那条查询，查出来的结果就是 1，3，5，7，那么按照文档里描述的，对于这几条记录都会加上next-key lock，也就是(-∞, 1], (1, 3], (3, 5], (5, 7], (7, 10) 这些区间和记录会被锁起来，不让插入，再唠叨一下呢，就是其实如果是只读的事务，光 read view 一致性读就够了，如果是有写操作的呢，就需要锁了。
聊聊 mysql 的 MVCC
很久以前，有位面试官问到，你知道 mysql 的事务隔离级别吗，“额 O__O …，不太清楚”，完了之后我就去网上找相关的文章，找到了这篇MySQL 四种事务隔离级的说明, 文章写得特别好，看了这个就懂了各个事务隔离级别都是啥，不过看了这个之后多思考一下的话还是会发现问题，这么神奇的事务隔离级别是怎么实现的呢
其中 innodb 的事务隔离用到了标题里说到的 mvcc，Multiversion concurrency control, 直译过来就是多版本并发控制，先不讲这个究竟是个啥，考虑下如果纯猜测，这个事务隔离级别应该会是怎么样实现呢，愚钝的我想了下，可以在事务开始的时候拷贝一个表，这个可以支持 RR 级别，RC 级别就不支持了，而且要是个非常大的表，想想就不可行
腆着脸说虽然这个不可行，但是思路是对的，具体实行起来需要做一系列（肥肠多）的改动，首先根据我的理解，其实这个拷贝一个表是变成拷贝一条记录，但是如果有多个事务，那就得拷贝多次，这个问题其实可以借助版本管理系统来解释，在用版本管理系统，git 之类的之前，很原始的可能是开发完一个功能后，就打个压缩包用时间等信息命名，然后如果后面要找回这个就直接用这个压缩包的就行了，后来有了 svn，git 中心式和分布式的版本管理系统，它的一个特点是粒度可以控制到文件和代码行级别，对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别，可能之前很多人都了解过，数据库的一行记录除了我们用户自定义的字段，还有一些额外的字段，去源码data0type.h里捞一下
/* Precise data types for system columns and the length of those columns;
NOTE: the values must run from 0 up in the order given! All codes must
be less than 256 */
#define DATA_ROW_ID 0 /* row id: a 48-bit integer */
diff --git a/page/22/index.html b/page/22/index.html
index d4eef79048..523b41a657 100644
--- a/page/22/index.html
+++ b/page/22/index.html
@@ -948,7 +948,7 @@ timelimit = config_cycle_slow_time_perc*1000000/server.hz/100;} else {
return (real == null) ? 0 : real.compare(a, b);
}
- }
核心代码就是下面这段，其实就是帮我们把前面要做的事情做掉了，是不是挺方便的，小记一下哈
docker使用中发现的echo命令的一个小技巧及其他
最近做 docker 系列，会经常进到 docker 内部，如上一篇介绍的，这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包，如果构建镜像的时候没有替换源的话，因为你懂的原因，在内部想编辑下东西要安装 vim 就会很慢很慢，thousand years later~
而且如果在容器内部想改源配置的话也要编辑器，就陷入了一个鸡生蛋，跟蛋生鸡的问题中，对于 linux 大神来说应该有一万种方法解决这个问题，对于我这个渣渣来说可能只想到了这个土方法，先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题，这个 sources.list 一般不止一行，直接 echo 的话就解析不了了，不过 echo 可以支持”\n”转义，就是加-e
看一下解释和示例
![]()
还有一点也是在这个时候要安装 vim 之类的，得知道是什么镜像底包，如果是用 uname 指令，其实看到的是宿主机的系统，得用cat /etc/issue
![]()
这里稍稍记一下
docker使用中发现的echo命令的一个小技巧及其他
最近做 docker 系列，会经常进到 docker 内部，如上一篇介绍的，这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包，如果构建镜像的时候没有替换源的话，因为你懂的原因，在内部想编辑下东西要安装 vim 就会很慢很慢，thousand years later~
而且如果在容器内部想改源配置的话也要编辑器，就陷入了一个鸡生蛋，跟蛋生鸡的问题中，对于 linux 大神来说应该有一万种方法解决这个问题，对于我这个渣渣来说可能只想到了这个土方法，先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题，这个 sources.list 一般不止一行，直接 echo 的话就解析不了了，不过 echo 可以支持”\n”转义，就是加-e
看一下解释和示例
![]()
还有一点也是在这个时候要安装 vim 之类的，得知道是什么镜像底包，如果是用 uname 指令，其实看到的是宿主机的系统，得用cat /etc/issue
![]()
这里稍稍记一下
docker比一般多一点的初学者介绍三
运行第一个 Dockerfile
上一篇的 Dockerfile 我们停留在构建阶段，现在来把它跑起来
docker run -d -p 80 --name static_web nicksxs/static_web \
nginx -g "daemon off;"
这里的-d表示以分离模型运行docker (detached),然后-p 是表示将容器的 80 端口开放给宿主机，然后容器名就叫 static_web,使用了我们上次构建的 static_web 镜像，后面的是让 nginx 在前台运行
![]()
可以看到返回了个容器 id，但是具体情况没出现，也没连上去，那我们想看看怎么访问在 Dockerfile 里写的静态页面，我们来看下docker 进程
![]()
发现为我们随机分配了一个宿主机的端口，32768，去服务器的防火墙把这个外网端口开一下，看看是不是符合我们的预期呢
![]()
好像不太对额，应该是 ubuntu 安装的 nginx 的默认工作目录不对，我们来进容器看看，再熟悉下命令docker exec -it 4792455ca2ed /bin/bash
记得容器 id 换成自己的，进入容器后得找找 nginx 的配置文件，通常在/etc/nginx,/usr/local/etc等目录下，然后找到我们的目录是在这
![]()
所以把刚才的内容复制过去再试试
![]()
目标达成，give me five✌️
第二个 Dockerfile
然后就想来动态一点的，毕竟写过 PHP，就来试试 PHP
再建一个目录叫 dynamic_web，里面创建 src 目录，放一个 index.php
内容是
<?php
echo "Hello World!";
然后在 dynamic_web 目录下创建 Dockerfile，
FROM trafex/alpine-nginx-php7:latest
COPY src/ /var/www/html
diff --git a/search.xml b/search.xml
index a0f7503858..9594538129 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/
@@ -49,6 +29,26 @@
2019
+
+ 村上春树《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 年终总结
/2021/03/31/2020-%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
@@ -74,88 +74,6 @@
拖更
-
- 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
- 拖更
-
-
-
- 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 这个坎徘徊，等于浪费了大半年，可能是年初的项目太费心力，压力比较大，吃得更多，是不是可以算工伤😄，这方面也需要好好调整，可以放得开一点，虽然不太可能一下子到位，但是总要去努力下，随着年龄成长总要承担更多，也要看得开一点，没法事事如愿，尽力就好了，减肥这个事情还在结合一些俯卧撑啥的，希望也能坚持下去，加油吧，不知道原话怎么说的，意思是人类最大的勇敢就是看透了人世间的苦难，仍然热爱生活。我当然没可能让内心变得这么强大，试着去努力吧，奥力给！
-]]>
-
- 生活
- 年中总结
- 2020
-
-
- 生活
- 2020
- 年中总结
-
-
-
- 34_Search_for_a_Range
- /2016/08/14/34-Search-for-a-Range/
- question34. Search for a Range
-Given a sorted array of integers, find the starting and ending position of a given target value.
-Your algorithm’s runtime complexity must be in the order of O(log n).
-If the target is not found in the array, return [-1, -1].
-For example,
Given [5, 7, 7, 8, 8, 10] and target value 8,
return [3, 4].
-analysis
一开始就想到了二分查找，但是原来做二分查找的时候一般都是找到确定的那个数就完成了，
这里的情况比较特殊，需要找到整个区间，所以需要两遍查找，并且一个是找到小于target
的最大索引，一个是找到大于target的最大索引，代码参考leetcode discuss,这位仁
兄也做了详细的分析解释。
-code
class Solution {
-public:
- vector<int> searchRange(vector<int>& nums, int target) {
- vector<int> ret(2, -1);
- int i = 0, j = nums.size() - 1;
- int mid;
- while(i < j){
- mid = (i + j) / 2;
- if(nums[mid] < target) i = mid + 1;
- else j = mid;
- }
- if(nums[i] != target) return ret;
- else {
- ret[0] = i;
- if((i+1) < (nums.size() - 1) && nums[i+1] > target){
- ret[1] = i;
- return ret;
- }
- } //一点小优化
- j = nums.size() - 1;
- while(i < j){
- mid = (i + j) / 2 + 1;
- if(nums[mid] > target) j = mid - 1;
- else i = mid;
- }
- ret[1] = j;
- return ret;
- }
-};
]]>
-
- leetcode
-
-
- leetcode
- c++
-
-
2021 年中总结
/2021/07/18/2021-%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
@@ -174,9 +92,26 @@ public:
生活
2021
- 年中总结
技术
读书
+ 年中总结
+
+
+
+ 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,116 +612,247 @@ public:
- add-two-number
- /2015/04/14/Add-Two-Number/
- problemYou are given two linked lists representing two non-negative numbers. The digits are stored in reverse order and each of their nodes contain a single digit. Add the two numbers and return it as a linked list.
-Input:(2 -> 4 -> 3) + (5 -> 6 -> 4)
Output: 7 -> 0 -> 8
-分析（不用英文装逼了）
这个代码是抄来的，链接原作是这位大大。
-
-一开始没看懂题，后来发现是要进位的，自己写的时候想把长短不同时长的串接到结果
串的后面，试了下因为进位会有些问题比较难搞定，这样的话就是在其中一个为空的
时候还是会循环操作，在链表太大的时候可能会有问题，就这样（逃
原来是有个小错误没发现，改进后的代码也AC了，棒棒哒！
-正确代码
/**
- * Definition for singly-linked list.
- * struct ListNode {
- * int val;
- * ListNode *next;
- * ListNode(int x) : val(x), next(NULL) {}
- * };
- */
-class Solution {
-public:
- ListNode *addTwoNumbers(ListNode *l1, ListNode *l2) {
- ListNode dummy(0);
- ListNode* p = &dummy;
-
- int cn = 0;
- while(l1 || l2){
- int val = cn + (l1 ? l1->val : 0) + (l2 ? l2->val : 0);
- cn = val / 10;
- val = val % 10;
- p->next = new ListNode(val);
- p = p->next;
- if(l1){
- l1 = l1->next;
- }
- if(l2){
- l2 = l2->next;
- }
- }
- if(cn != 0){
- p->next = new ListNode(cn);
- p = p->next;
- }
- return dummy.next;
- }
-};
-
-失败的代码
/**
- * Definition for singly-linked list.
- * struct ListNode {
- * int val;
- * ListNode *next;
- * ListNode(int x) : val(x), next(NULL) {}
- * };
- */
-class Solution {
-public:
- ListNode *addTwoNumbers(ListNode *l1, ListNode *l2) {
- ListNode dummy(0);
- ListNode* p = &dummy;
-
- int cn = 0;
- int flag = 0;
- while(l1 || l2){
- int val = cn + (l1 ? l1->val : 0) + (l2 ? l2->val : 0);
- cn = val / 10;
- val = val % 10;
- p->next = new ListNode(val);
- p = p->next;
- if(!l1 && cn == 0){
- flag = 1;
- break;
- }
- if(!l2 && cn == 0){
- flag = 1;
- break;
- }
- if(l1){
- l1 = l1->next;
- }
- if(l2){
- l2 = l2->next;
- }
- }
- if(!l1 && cn == 0 && flag == 1){
- p->next = l2->next;
- }
- if(!l2 && cn == 0 && flag == 1){
- p->next = l1->next;
- }
- if(cn != 0){
- p->next = new ListNode(cn);
- p = p->next;
- }
- return dummy.next;
- }
-};
+ 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 这个坎徘徊，等于浪费了大半年，可能是年初的项目太费心力，压力比较大，吃得更多，是不是可以算工伤😄，这方面也需要好好调整，可以放得开一点，虽然不太可能一下子到位，但是总要去努力下，随着年龄成长总要承担更多，也要看得开一点，没法事事如愿，尽力就好了，减肥这个事情还在结合一些俯卧撑啥的，希望也能坚持下去，加油吧，不知道原话怎么说的，意思是人类最大的勇敢就是看透了人世间的苦难，仍然热爱生活。我当然没可能让内心变得这么强大，试着去努力吧，奥力给！
]]>
- leetcode
+ 生活
+ 年中总结
+ 2020
- leetcode
- c++
+ 生活
+ 2020
+ 年中总结
- Apollo 的 value 注解是怎么自动更新的
- /2020/11/01/Apollo-%E7%9A%84-value-%E6%B3%A8%E8%A7%A3%E6%98%AF%E6%80%8E%E4%B9%88%E8%87%AA%E5%8A%A8%E6%9B%B4%E6%96%B0%E7%9A%84/
- 在前司和目前公司，用的配置中心都是使用的 Apollo，经过了业界验证，比较强大的配置管理系统，特别是在0.10 后开始支持对使用 value 注解的配置值进行自动更新，今天刚好有个同学问到我，就顺便写篇文章记录下，其实也是借助于 spring 强大的 bean 生命周期管理，可以实现BeanPostProcessor接口，使用postProcessBeforeInitialization方法，来对bean 内部的属性和方法进行判断，是否有 value 注解，如果有就是将它注册到一个 map 中，可以看到这个方法com.ctrip.framework.apollo.spring.annotation.SpringValueProcessor#processField
-@Override
- protected void processField(Object bean, String beanName, Field field) {
- // register @Value on field
- Value value = field.getAnnotation(Value.class);
+ 34_Search_for_a_Range
+ /2016/08/14/34-Search-for-a-Range/
+ question34. Search for a Range
+Given a sorted array of integers, find the starting and ending position of a given target value.
+Your algorithm’s runtime complexity must be in the order of O(log n).
+If the target is not found in the array, return [-1, -1].
+For example,
Given [5, 7, 7, 8, 8, 10] and target value 8,
return [3, 4].
+analysis
一开始就想到了二分查找，但是原来做二分查找的时候一般都是找到确定的那个数就完成了，
这里的情况比较特殊，需要找到整个区间，所以需要两遍查找，并且一个是找到小于target
的最大索引，一个是找到大于target的最大索引，代码参考leetcode discuss,这位仁
兄也做了详细的分析解释。
+code
class Solution {
+public:
+ vector<int> searchRange(vector<int>& nums, int target) {
+ vector<int> ret(2, -1);
+ int i = 0, j = nums.size() - 1;
+ int mid;
+ while(i < j){
+ mid = (i + j) / 2;
+ if(nums[mid] < target) i = mid + 1;
+ else j = mid;
+ }
+ if(nums[i] != target) return ret;
+ else {
+ ret[0] = i;
+ if((i+1) < (nums.size() - 1) && nums[i+1] > target){
+ ret[1] = i;
+ return ret;
+ }
+ } //一点小优化
+ j = nums.size() - 1;
+ while(i < j){
+ mid = (i + j) / 2 + 1;
+ if(nums[mid] > target) j = mid - 1;
+ else i = mid;
+ }
+ ret[1] = j;
+ return ret;
+ }
+};
]]>
+
+ leetcode
+
+
+ leetcode
+ c++
+
+
+
+ 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
+ */
+ // 同样的不分析，略过吧
+ static final int PROPAGATE = -3;
+ // =====================================================
+
+
+ // 取值为上面的1、-1、-2、-3，或者0(以后会讲到)
+ // 这么理解，暂时只需要知道如果这个值 大于0 代表此线程取消了等待，
+ // ps: 半天抢不到锁，不抢了，ReentrantLock是可以指定timeouot的。。。
+ volatile int waitStatus;
+ // 前驱节点的引用
+ volatile Node prev;
+ // 后继节点的引用
+ volatile Node next;
+ // 这个就是线程本尊
+ volatile Thread thread;
+
+}
+其实可以主要关注这个 waitStatus 因为这个是后面的节点给前面的节点设置的，等于-1 的时候代表后面有节点等待，需要去唤醒，
这里使用了一个变种的 CLH 队列实现，CLH 队列相关内容可以查看这篇 自旋锁、排队自旋锁、MCS锁、CLH锁
+]]>
+
+ java
+
+
+ java
+ aqs
+
+
+
+ add-two-number
+ /2015/04/14/Add-Two-Number/
+ problemYou are given two linked lists representing two non-negative numbers. The digits are stored in reverse order and each of their nodes contain a single digit. Add the two numbers and return it as a linked list.
+Input:(2 -> 4 -> 3) + (5 -> 6 -> 4)
Output: 7 -> 0 -> 8
+分析（不用英文装逼了）
这个代码是抄来的，链接原作是这位大大。
+
+一开始没看懂题，后来发现是要进位的，自己写的时候想把长短不同时长的串接到结果
串的后面，试了下因为进位会有些问题比较难搞定，这样的话就是在其中一个为空的
时候还是会循环操作，在链表太大的时候可能会有问题，就这样（逃
原来是有个小错误没发现，改进后的代码也AC了，棒棒哒！
+正确代码
/**
+ * Definition for singly-linked list.
+ * struct ListNode {
+ * int val;
+ * ListNode *next;
+ * ListNode(int x) : val(x), next(NULL) {}
+ * };
+ */
+class Solution {
+public:
+ ListNode *addTwoNumbers(ListNode *l1, ListNode *l2) {
+ ListNode dummy(0);
+ ListNode* p = &dummy;
+
+ int cn = 0;
+ while(l1 || l2){
+ int val = cn + (l1 ? l1->val : 0) + (l2 ? l2->val : 0);
+ cn = val / 10;
+ val = val % 10;
+ p->next = new ListNode(val);
+ p = p->next;
+ if(l1){
+ l1 = l1->next;
+ }
+ if(l2){
+ l2 = l2->next;
+ }
+ }
+ if(cn != 0){
+ p->next = new ListNode(cn);
+ p = p->next;
+ }
+ return dummy.next;
+ }
+};
+
+失败的代码
/**
+ * Definition for singly-linked list.
+ * struct ListNode {
+ * int val;
+ * ListNode *next;
+ * ListNode(int x) : val(x), next(NULL) {}
+ * };
+ */
+class Solution {
+public:
+ ListNode *addTwoNumbers(ListNode *l1, ListNode *l2) {
+ ListNode dummy(0);
+ ListNode* p = &dummy;
+
+ int cn = 0;
+ int flag = 0;
+ while(l1 || l2){
+ int val = cn + (l1 ? l1->val : 0) + (l2 ? l2->val : 0);
+ cn = val / 10;
+ val = val % 10;
+ p->next = new ListNode(val);
+ p = p->next;
+ if(!l1 && cn == 0){
+ flag = 1;
+ break;
+ }
+ if(!l2 && cn == 0){
+ flag = 1;
+ break;
+ }
+ if(l1){
+ l1 = l1->next;
+ }
+ if(l2){
+ l2 = l2->next;
+ }
+ }
+ if(!l1 && cn == 0 && flag == 1){
+ p->next = l2->next;
+ }
+ if(!l2 && cn == 0 && flag == 1){
+ p->next = l1->next;
+ }
+ if(cn != 0){
+ p->next = new ListNode(cn);
+ p = p->next;
+ }
+ return dummy.next;
+ }
+};
+]]>
+
+ leetcode
+
+
+ leetcode
+ c++
+
+
+
+ Apollo 的 value 注解是怎么自动更新的
+ /2020/11/01/Apollo-%E7%9A%84-value-%E6%B3%A8%E8%A7%A3%E6%98%AF%E6%80%8E%E4%B9%88%E8%87%AA%E5%8A%A8%E6%9B%B4%E6%96%B0%E7%9A%84/
+ 在前司和目前公司，用的配置中心都是使用的 Apollo，经过了业界验证，比较强大的配置管理系统，特别是在0.10 后开始支持对使用 value 注解的配置值进行自动更新，今天刚好有个同学问到我，就顺便写篇文章记录下，其实也是借助于 spring 强大的 bean 生命周期管理，可以实现BeanPostProcessor接口，使用postProcessBeforeInitialization方法，来对bean 内部的属性和方法进行判断，是否有 value 注解，如果有就是将它注册到一个 map 中，可以看到这个方法com.ctrip.framework.apollo.spring.annotation.SpringValueProcessor#processField
+@Override
+ protected void processField(Object bean, String beanName, Field field) {
+ // register @Value on field
+ Value value = field.getAnnotation(Value.class);
if (value == null) {
return;
}
@@ -1148,170 +1214,42 @@ Node *clone(Node *graph) {
- AbstractQueuedSynchronizer
- /2019/09/23/AbstractQueuedSynchronizer/
- 最近看了大神的 AQS 的文章，之前总是断断续续地看一点，每次都知难而退，下次看又从头开始，昨天总算硬着头皮看完了第一部分
首先 AQS 只要有这些属性
-// 头结点，你直接把它当做 当前持有锁的线程 可能是最好理解的
-private transient volatile Node head;
+ 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;
+}
-// 阻塞的尾节点，每个新的节点进来，都插入到最后，也就形成了一个链表
-private transient volatile Node tail;
+class Value extends LhsPadding
+{
+ protected volatile long value;
+}
-// 这个是最重要的，代表当前锁的状态，0代表没有被占用，大于 0 代表有线程持有当前锁
-// 这个值可以大于 1，是因为锁可以重入，每次重入都加上 1
-private volatile int state;
+class RhsPadding extends Value
+{
+ protected long p9, p10, p11, p12, p13, p14, p15;
+}
-// 代表当前持有独占锁的线程，举个最重要的使用例子，因为锁可以重入
-// 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
- */
- // 同样的不分析，略过吧
- static final int PROPAGATE = -3;
- // =====================================================
-
-
- // 取值为上面的1、-1、-2、-3，或者0(以后会讲到)
- // 这么理解，暂时只需要知道如果这个值 大于0 代表此线程取消了等待，
- // ps: 半天抢不到锁，不抢了，ReentrantLock是可以指定timeouot的。。。
- volatile int waitStatus;
- // 前驱节点的引用
- volatile Node prev;
- // 后继节点的引用
- volatile Node next;
- // 这个就是线程本尊
- volatile Thread thread;
-
-}
-其实可以主要关注这个 waitStatus 因为这个是后面的节点给前面的节点设置的，等于-1 的时候代表后面有节点等待，需要去唤醒，
这里使用了一个变种的 CLH 队列实现，CLH 队列相关内容可以查看这篇 自旋锁、排队自旋锁、MCS锁、CLH锁
-]]>
-
- java
-
-
- java
- aqs
-
-
-
- Comparator使用小记
- /2020/04/05/Comparator%E4%BD%BF%E7%94%A8%E5%B0%8F%E8%AE%B0/
- 在Java8的stream之前，将对象进行排序的时候，可能需要对象实现Comparable接口，或者自己实现一个Comparator，
-比如这样子
-我的对象是Entity
-public class Entity {
-
- private Long id;
-
- private Long sortValue;
-
- public Long getId() {
- return id;
- }
-
- public void setId(Long id) {
- this.id = id;
- }
-
- public Long getSortValue() {
- return sortValue;
- }
-
- public void setSortValue(Long sortValue) {
- this.sortValue = sortValue;
- }
-}
-
-Comparator
-public class MyComparator implements Comparator {
- @Override
- public int compare(Object o1, Object o2) {
- Entity e1 = (Entity) o1;
- Entity e2 = (Entity) o2;
- if (e1.getSortValue() < e2.getSortValue()) {
- return -1;
- } else if (e1.getSortValue().equals(e2.getSortValue())) {
- return 0;
- } else {
- return 1;
- }
- }
-}
-
-比较代码
-private static MyComparator myComparator = new MyComparator();
-
- public static void main(String[] args) {
- List<Entity> list = new ArrayList<Entity>();
- Entity e1 = new Entity();
- e1.setId(1L);
- e1.setSortValue(1L);
- list.add(e1);
- Entity e2 = new Entity();
- e2.setId(2L);
- e2.setSortValue(null);
- list.add(e2);
- Collections.sort(list, myComparator);
-
-看到这里的e2的排序值是null，在Comparator中如果要正常运行的话，就得判空之类的，这里有两点需要，一个是不想写这个MyComparator，然后也没那么好排除掉list里排序值，那么有什么办法能解决这种问题呢，应该说java的这方面真的是很强大
-![]()
-看一下nullsFirst的实现
-final static class NullComparator<T> implements Comparator<T>, Serializable {
- private static final long serialVersionUID = -7569533591570686392L;
- private final boolean nullFirst;
- // if null, non-null Ts are considered equal
- private final Comparator<T> real;
-
- @SuppressWarnings("unchecked")
- NullComparator(boolean nullFirst, Comparator<? super T> real) {
- this.nullFirst = nullFirst;
- this.real = (Comparator<T>) real;
- }
-
- @Override
- public int compare(T a, T b) {
- if (a == null) {
- return (b == null) ? 0 : (nullFirst ? -1 : 1);
- } else if (b == null) {
- return nullFirst ? 1: -1;
- } else {
- return (real == null) ? 0 : real.compare(a, b);
- }
- }
-
-核心代码就是下面这段，其实就是帮我们把前面要做的事情做掉了，是不是挺方便的，小记一下哈
+/**
+ * <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
- Stream
- Comparator
- 排序
- sort
- nullsfirst
+ Disruptor
@@ -1865,310 +1803,572 @@ Node *clone(Node *graph) {
- JVM源码分析之G1垃圾收集器分析一
- /2019/12/07/JVM-G1-Part-1/
- 对 Java 的 gc 实现比较感兴趣，原先一般都是看周志明的书，但其实并没有讲具体的 gc 源码，而是把整个思路和流程讲解了一下
特别是 G1 的具体实现
一般对 G1 的理解其实就是把原先整块的新生代老年代分成了以 region 为单位的小块内存，简而言之，就是原先对新生代老年代的收集会涉及到整个代的堆内存空间，而G1 把它变成了更细致的小块内存
这带来了一个很明显的好处和一个很明显的坏处，好处是内存收集可以更灵活，耗时会变短，但整个收集的处理复杂度就变高了
目前看了一点点关于 G1 收集的预期时间相关的代码
-HeapWord* G1CollectedHeap::do_collection_pause(size_t word_size,
- uint gc_count_before,
- bool* succeeded,
- GCCause::Cause gc_cause) {
- assert_heap_not_locked_and_not_at_safepoint();
- VM_G1CollectForAllocation op(word_size,
- gc_count_before,
- gc_cause,
- false, /* should_initiate_conc_mark */
- g1_policy()->max_pause_time_ms());
- VMThread::execute(&op);
-
- HeapWord* result = op.result();
- bool ret_succeeded = op.prologue_succeeded() && op.pause_succeeded();
- assert(result == NULL || ret_succeeded,
- "the result should be NULL if the VM did not succeed");
- *succeeded = ret_succeeded;
+ Comparator使用小记
+ /2020/04/05/Comparator%E4%BD%BF%E7%94%A8%E5%B0%8F%E8%AE%B0/
+ 在Java8的stream之前，将对象进行排序的时候，可能需要对象实现Comparable接口，或者自己实现一个Comparator，
+比如这样子
+我的对象是Entity
+public class Entity {
- assert_heap_not_locked();
- return result;
-}
-这里就是收集时需要停顿的，其中VMThread::execute(&op);是具体执行的，真正执行的是VM_G1CollectForAllocation::doit方法
-void VM_G1CollectForAllocation::doit() {
- G1CollectedHeap* g1h = G1CollectedHeap::heap();
- assert(!_should_initiate_conc_mark || g1h->should_do_concurrent_full_gc(_gc_cause),
- "only a GC locker, a System.gc(), stats update, whitebox, or a hum allocation induced GC should start a cycle");
+ private Long id;
- if (_word_size > 0) {
- // An allocation has been requested. So, try to do that first.
- _result = g1h->attempt_allocation_at_safepoint(_word_size,
- false /* expect_null_cur_alloc_region */);
- if (_result != NULL) {
- // If we can successfully allocate before we actually do the
- // pause then we will consider this pause successful.
- _pause_succeeded = true;
- return;
- }
- }
+ private Long sortValue;
- GCCauseSetter x(g1h, _gc_cause);
- if (_should_initiate_conc_mark) {
- // It's safer to read old_marking_cycles_completed() here, given
- // that noone else will be updating it concurrently. Since we'll
- // only need it if we're initiating a marking cycle, no point in
- // setting it earlier.
- _old_marking_cycles_completed_before = g1h->old_marking_cycles_completed();
+ public Long getId() {
+ return id;
+ }
- // At this point we are supposed to start a concurrent cycle. We
- // will do so if one is not already in progress.
- bool res = g1h->g1_policy()->force_initial_mark_if_outside_cycle(_gc_cause);
+ public void setId(Long id) {
+ this.id = id;
+ }
- // The above routine returns true if we were able to force the
- // next GC pause to be an initial mark; it returns false if a
- // marking cycle is already in progress.
- //
- // If a marking cycle is already in progress just return and skip the
- // pause below - if the reason for requesting this initial mark pause
- // was due to a System.gc() then the requesting thread should block in
- // doit_epilogue() until the marking cycle is complete.
- //
- // If this initial mark pause was requested as part of a humongous
- // allocation then we know that the marking cycle must just have
- // been started by another thread (possibly also allocating a humongous
- // object) as there was no active marking cycle when the requesting
- // thread checked before calling collect() in
- // attempt_allocation_humongous(). Retrying the GC, in this case,
- // will cause the requesting thread to spin inside collect() until the
- // just started marking cycle is complete - which may be a while. So
- // we do NOT retry the GC.
- if (!res) {
- assert(_word_size == 0, "Concurrent Full GC/Humongous Object IM shouldn't be allocating");
- if (_gc_cause != GCCause::_g1_humongous_allocation) {
- _should_retry_gc = true;
- }
- return;
- }
- }
+ public Long getSortValue() {
+ return sortValue;
+ }
- // Try a partial collection of some kind.
- _pause_succeeded = g1h->do_collection_pause_at_safepoint(_target_pause_time_ms);
+ public void setSortValue(Long sortValue) {
+ this.sortValue = sortValue;
+ }
+}
- if (_pause_succeeded) {
- if (_word_size > 0) {
- // An allocation had been requested. Do it, eventually trying a stronger
- // kind of GC.
- _result = g1h->satisfy_failed_allocation(_word_size, &_pause_succeeded);
- } else {
- bool should_upgrade_to_full = !g1h->should_do_concurrent_full_gc(_gc_cause) &&
- !g1h->has_regions_left_for_allocation();
- if (should_upgrade_to_full) {
- // There has been a request to perform a GC to free some space. We have no
- // information on how much memory has been asked for. In case there are
- // absolutely no regions left to allocate into, do a maximally compacting full GC.
- log_info(gc, ergo)("Attempting maximally compacting collection");
- _pause_succeeded = g1h->do_full_collection(false, /* explicit gc */
- true /* clear_all_soft_refs */);
- }
- }
- guarantee(_pause_succeeded, "Elevated collections during the safepoint must always succeed.");
- } else {
- assert(_result == NULL, "invariant");
- // The only reason for the pause to not be successful is that, the GC locker is
- // active (or has become active since the prologue was executed). In this case
- // we should retry the pause after waiting for the GC locker to become inactive.
- _should_retry_gc = true;
- }
-}
-这里可以看到核心的是G1CollectedHeap::do_collection_pause_at_safepoint这个方法，它带上了目标暂停时间的值
-G1CollectedHeap::do_collection_pause_at_safepoint(double target_pause_time_ms) {
- assert_at_safepoint_on_vm_thread();
- guarantee(!is_gc_active(), "collection is not reentrant");
-
- if (GCLocker::check_active_before_gc()) {
- return false;
- }
-
- _gc_timer_stw->register_gc_start();
-
- GCIdMark gc_id_mark;
- _gc_tracer_stw->report_gc_start(gc_cause(), _gc_timer_stw->gc_start());
-
- SvcGCMarker sgcm(SvcGCMarker::MINOR);
- ResourceMark rm;
-
- g1_policy()->note_gc_start();
-
- wait_for_root_region_scanning();
-
- print_heap_before_gc();
- print_heap_regions();
- trace_heap_before_gc(_gc_tracer_stw);
-
- _verifier->verify_region_sets_optional();
- _verifier->verify_dirty_young_regions();
-
- // We should not be doing initial mark unless the conc mark thread is running
- if (!_cm_thread->should_terminate()) {
- // This call will decide whether this pause is an initial-mark
- // pause. If it is, in_initial_mark_gc() will return true
- // for the duration of this pause.
- g1_policy()->decide_on_conc_mark_initiation();
- }
-
- // We do not allow initial-mark to be piggy-backed on a mixed GC.
- assert(!collector_state()->in_initial_mark_gc() ||
- collector_state()->in_young_only_phase(), "sanity");
-
- // We also do not allow mixed GCs during marking.
- assert(!collector_state()->mark_or_rebuild_in_progress() || collector_state()->in_young_only_phase(), "sanity");
-
- // Record whether this pause is an initial mark. When the current
- // thread has completed its logging output and it's safe to signal
- // the CM thread, the flag's value in the policy has been reset.
- bool should_start_conc_mark = collector_state()->in_initial_mark_gc();
-
- // Inner scope for scope based logging, timers, and stats collection
- {
- EvacuationInfo evacuation_info;
-
- if (collector_state()->in_initial_mark_gc()) {
- // We are about to start a marking cycle, so we increment the
- // full collection counter.
- increment_old_marking_cycles_started();
- _cm->gc_tracer_cm()->set_gc_cause(gc_cause());
- }
+Comparator
+public class MyComparator implements Comparator {
+ @Override
+ public int compare(Object o1, Object o2) {
+ Entity e1 = (Entity) o1;
+ Entity e2 = (Entity) o2;
+ if (e1.getSortValue() < e2.getSortValue()) {
+ return -1;
+ } else if (e1.getSortValue().equals(e2.getSortValue())) {
+ return 0;
+ } else {
+ return 1;
+ }
+ }
+}
- _gc_tracer_stw->report_yc_type(collector_state()->yc_type());
+比较代码
+private static MyComparator myComparator = new MyComparator();
- GCTraceCPUTime tcpu;
+ public static void main(String[] args) {
+ List<Entity> list = new ArrayList<Entity>();
+ Entity e1 = new Entity();
+ e1.setId(1L);
+ e1.setSortValue(1L);
+ list.add(e1);
+ Entity e2 = new Entity();
+ e2.setId(2L);
+ e2.setSortValue(null);
+ list.add(e2);
+ Collections.sort(list, myComparator);
- G1HeapVerifier::G1VerifyType verify_type;
- FormatBuffer<> gc_string("Pause Young ");
- if (collector_state()->in_initial_mark_gc()) {
- gc_string.append("(Concurrent Start)");
- verify_type = G1HeapVerifier::G1VerifyConcurrentStart;
- } else if (collector_state()->in_young_only_phase()) {
- if (collector_state()->in_young_gc_before_mixed()) {
- gc_string.append("(Prepare Mixed)");
- } else {
- gc_string.append("(Normal)");
- }
- verify_type = G1HeapVerifier::G1VerifyYoungNormal;
- } else {
- gc_string.append("(Mixed)");
- verify_type = G1HeapVerifier::G1VerifyMixed;
- }
- GCTraceTime(Info, gc) tm(gc_string, NULL, gc_cause(), true);
+看到这里的e2的排序值是null，在Comparator中如果要正常运行的话，就得判空之类的，这里有两点需要，一个是不想写这个MyComparator，然后也没那么好排除掉list里排序值，那么有什么办法能解决这种问题呢，应该说java的这方面真的是很强大
+![]()
+看一下nullsFirst的实现
+final static class NullComparator<T> implements Comparator<T>, Serializable {
+ private static final long serialVersionUID = -7569533591570686392L;
+ private final boolean nullFirst;
+ // if null, non-null Ts are considered equal
+ private final Comparator<T> real;
- uint active_workers = AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(),
- workers()->active_workers(),
- Threads::number_of_non_daemon_threads());
- active_workers = workers()->update_active_workers(active_workers);
- log_info(gc,task)("Using %u workers of %u for evacuation", active_workers, workers()->total_workers());
+ @SuppressWarnings("unchecked")
+ NullComparator(boolean nullFirst, Comparator<? super T> real) {
+ this.nullFirst = nullFirst;
+ this.real = (Comparator<T>) real;
+ }
- TraceCollectorStats tcs(g1mm()->incremental_collection_counters());
- TraceMemoryManagerStats tms(&_memory_manager, gc_cause(),
- collector_state()->yc_type() == Mixed /* allMemoryPoolsAffected */);
+ @Override
+ public int compare(T a, T b) {
+ if (a == null) {
+ return (b == null) ? 0 : (nullFirst ? -1 : 1);
+ } else if (b == null) {
+ return nullFirst ? 1: -1;
+ } else {
+ return (real == null) ? 0 : real.compare(a, b);
+ }
+ }
- G1HeapTransition heap_transition(this);
- size_t heap_used_bytes_before_gc = used();
+核心代码就是下面这段，其实就是帮我们把前面要做的事情做掉了，是不是挺方便的，小记一下哈
+]]>
+
+ Java
+ 集合
+
+
+ Java
+ Stream
+ Comparator
+ 排序
+ sort
+ nullsfirst
+
+
+
+ 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;
- // Don't dynamically change the number of GC threads this early. A value of
- // 0 is used to indicate serial work. When parallel work is done,
- // it will be set.
+ public void set(long value) {
+ this.value = value;
+ }
- { // Call to jvmpi::post_class_unload_events must occur outside of active GC
- IsGCActiveMark x;
+ public long getValue() {
+ return value;
+ }
- gc_prologue(false);
+ 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> {
- if (VerifyRememberedSets) {
- log_info(gc, verify)("[Verifying RemSets before GC]");
- VerifyRegionRemSetClosure v_cl;
- heap_region_iterate(&v_cl);
- }
+ // 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;
- _verifier->verify_before_gc(verify_type);
+import com.lmax.disruptor.RingBuffer;
+import com.lmax.disruptor.dsl.Disruptor;
+import com.lmax.disruptor.util.DaemonThreadFactory;
- _verifier->check_bitmaps("GC Start");
+import java.nio.ByteBuffer;
-#if COMPILER2_OR_JVMCI
- DerivedPointerTable::clear();
-#endif
+public class LongEventMain
+{
+ public static void main(String[] args) throws Exception
+ {
+ // 这个需要是 2 的幂次，这样在定位的时候只需要位移操作，也能减少各种计算操作
+ int bufferSize = 1024;
- // Please see comment in g1CollectedHeap.hpp and
- // G1CollectedHeap::ref_processing_init() to see how
- // reference processing currently works in G1.
+ Disruptor<LongEvent> disruptor =
+ new Disruptor<>(LongEvent::new, bufferSize, DaemonThreadFactory.INSTANCE);
- // Enable discovery in the STW reference processor
- _ref_processor_stw->enable_discovery();
+ // 类似于注册处理器
+ disruptor.handleEventsWith(new LongEventHandler());
+ // 或者直接用 lambda
+ disruptor.handleEventsWith((event, sequence, endOfBatch) ->
+ System.out.println("Event: " + event));
+ // 启动我们的 disruptor
+ disruptor.start();
- {
- // We want to temporarily turn off discovery by the
- // CM ref processor, if necessary, and turn it back on
- // on again later if we do. Using a scoped
- // NoRefDiscovery object will do this.
- NoRefDiscovery no_cm_discovery(_ref_processor_cm);
- // Forget the current alloc region (we might even choose it to be part
- // of the collection set!).
- _allocator->release_mutator_alloc_region();
-
- // This timing is only used by the ergonomics to handle our pause target.
- // It is unclear why this should not include the full pause. We will
- // investigate this in CR 7178365.
- //
- // Preserving the old comment here if that helps the investigation:
- //
- // The elapsed time induced by the start time below deliberately elides
- // the possible verification above.
- double sample_start_time_sec = os::elapsedTime();
+ 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 021 合并两个有序链表 ( Merge Two Sorted Lists ) 题解分析
+ /2021/10/07/Leetcode-021-%E5%90%88%E5%B9%B6%E4%B8%A4%E4%B8%AA%E6%9C%89%E5%BA%8F%E9%93%BE%E8%A1%A8-Merge-Two-Sorted-Lists-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
+ 题目介绍Merge two sorted linked lists and return it as a sorted list. The list should be made by splicing together the nodes of the first two lists.
+将两个升序链表合并为一个新的 升序 链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。
+示例 1
![]()
+
+输入：l1 = [1,2,4], l2 = [1,3,4]
输出：[1,1,2,3,4,4]
+
+示例 2
+输入: l1 = [], l2 = []
输出: []
+
+示例 3
+输入: l1 = [], l2 = [0]
输出: [0]
+
+简要分析
这题是 Easy 的，看着也挺简单，两个链表进行合并，就是比较下大小，可能将就点的话最好就在两个链表中原地合并
+题解代码
public ListNode mergeTwoLists(ListNode l1, ListNode l2) {
+ // 下面两个if判断了入参的边界，如果其一为null，直接返回另一个就可以了
+ if (l1 == null) {
+ return l2;
+ }
+ if (l2 == null) {
+ return l1;
+ }
+ // new 一个合并后的头结点
+ ListNode merged = new ListNode();
+ // 这个是当前节点
+ ListNode current = merged;
+ // 一开始给这个while加了l1和l2不全为null的条件，后面想了下不需要
+ // 因为内部前两个if就是跳出条件
+ while (true) {
+ if (l1 == null) {
+ // 这里其实跟开头类似，只不过这里需要将l2剩余部分接到merged链表后面
+ // 所以不能是直接current = l2，这样就是把后面的直接丢了
+ current.val = l2.val;
+ current.next = l2.next;
+ break;
+ }
+ if (l2 == null) {
+ current.val = l1.val;
+ current.next = l1.next;
+ break;
+ }
+ // 这里是两个链表都不为空的时候，就比较下大小
+ if (l1.val < l2.val) {
+ current.val = l1.val;
+ l1 = l1.next;
+ } else {
+ current.val = l2.val;
+ l2 = l2.next;
+ }
+ // 这里是new个新的，其实也可以放在循环头上
+ current.next = new ListNode();
+ current = current.next;
+ }
+ current = null;
+ // 返回这个头结点
+ return merged;
+ }
- g1_policy()->record_collection_pause_start(sample_start_time_sec);
+结果
![]()
+]]>
+
+ Java
+ leetcode
+
+
+ leetcode
+ java
+ 题解
+
+
+
+ JVM源码分析之G1垃圾收集器分析一
+ /2019/12/07/JVM-G1-Part-1/
+ 对 Java 的 gc 实现比较感兴趣，原先一般都是看周志明的书，但其实并没有讲具体的 gc 源码，而是把整个思路和流程讲解了一下
特别是 G1 的具体实现
一般对 G1 的理解其实就是把原先整块的新生代老年代分成了以 region 为单位的小块内存，简而言之，就是原先对新生代老年代的收集会涉及到整个代的堆内存空间，而G1 把它变成了更细致的小块内存
这带来了一个很明显的好处和一个很明显的坏处，好处是内存收集可以更灵活，耗时会变短，但整个收集的处理复杂度就变高了
目前看了一点点关于 G1 收集的预期时间相关的代码
+HeapWord* G1CollectedHeap::do_collection_pause(size_t word_size,
+ uint gc_count_before,
+ bool* succeeded,
+ GCCause::Cause gc_cause) {
+ assert_heap_not_locked_and_not_at_safepoint();
+ VM_G1CollectForAllocation op(word_size,
+ gc_count_before,
+ gc_cause,
+ false, /* should_initiate_conc_mark */
+ g1_policy()->max_pause_time_ms());
+ VMThread::execute(&op);
- if (collector_state()->in_initial_mark_gc()) {
- concurrent_mark()->pre_initial_mark();
- }
+ HeapWord* result = op.result();
+ bool ret_succeeded = op.prologue_succeeded() && op.pause_succeeded();
+ assert(result == NULL || ret_succeeded,
+ "the result should be NULL if the VM did not succeed");
+ *succeeded = ret_succeeded;
- g1_policy()->finalize_collection_set(target_pause_time_ms, &_survivor);
+ assert_heap_not_locked();
+ return result;
+}
+这里就是收集时需要停顿的，其中VMThread::execute(&op);是具体执行的，真正执行的是VM_G1CollectForAllocation::doit方法
+void VM_G1CollectForAllocation::doit() {
+ G1CollectedHeap* g1h = G1CollectedHeap::heap();
+ assert(!_should_initiate_conc_mark || g1h->should_do_concurrent_full_gc(_gc_cause),
+ "only a GC locker, a System.gc(), stats update, whitebox, or a hum allocation induced GC should start a cycle");
- evacuation_info.set_collectionset_regions(collection_set()->region_length());
+ if (_word_size > 0) {
+ // An allocation has been requested. So, try to do that first.
+ _result = g1h->attempt_allocation_at_safepoint(_word_size,
+ false /* expect_null_cur_alloc_region */);
+ if (_result != NULL) {
+ // If we can successfully allocate before we actually do the
+ // pause then we will consider this pause successful.
+ _pause_succeeded = true;
+ return;
+ }
+ }
- // Make sure the remembered sets are up to date. This needs to be
- // done before register_humongous_regions_with_cset(), because the
- // remembered sets are used there to choose eager reclaim candidates.
- // If the remembered sets are not up to date we might miss some
- // entries that need to be handled.
- g1_rem_set()->cleanupHRRS();
+ GCCauseSetter x(g1h, _gc_cause);
+ if (_should_initiate_conc_mark) {
+ // It's safer to read old_marking_cycles_completed() here, given
+ // that noone else will be updating it concurrently. Since we'll
+ // only need it if we're initiating a marking cycle, no point in
+ // setting it earlier.
+ _old_marking_cycles_completed_before = g1h->old_marking_cycles_completed();
- register_humongous_regions_with_cset();
+ // At this point we are supposed to start a concurrent cycle. We
+ // will do so if one is not already in progress.
+ bool res = g1h->g1_policy()->force_initial_mark_if_outside_cycle(_gc_cause);
- assert(_verifier->check_cset_fast_test(), "Inconsistency in the InCSetState table.");
+ // The above routine returns true if we were able to force the
+ // next GC pause to be an initial mark; it returns false if a
+ // marking cycle is already in progress.
+ //
+ // If a marking cycle is already in progress just return and skip the
+ // pause below - if the reason for requesting this initial mark pause
+ // was due to a System.gc() then the requesting thread should block in
+ // doit_epilogue() until the marking cycle is complete.
+ //
+ // If this initial mark pause was requested as part of a humongous
+ // allocation then we know that the marking cycle must just have
+ // been started by another thread (possibly also allocating a humongous
+ // object) as there was no active marking cycle when the requesting
+ // thread checked before calling collect() in
+ // attempt_allocation_humongous(). Retrying the GC, in this case,
+ // will cause the requesting thread to spin inside collect() until the
+ // just started marking cycle is complete - which may be a while. So
+ // we do NOT retry the GC.
+ if (!res) {
+ assert(_word_size == 0, "Concurrent Full GC/Humongous Object IM shouldn't be allocating");
+ if (_gc_cause != GCCause::_g1_humongous_allocation) {
+ _should_retry_gc = true;
+ }
+ return;
+ }
+ }
- // We call this after finalize_cset() to
- // ensure that the CSet has been finalized.
- _cm->verify_no_cset_oops();
+ // Try a partial collection of some kind.
+ _pause_succeeded = g1h->do_collection_pause_at_safepoint(_target_pause_time_ms);
- if (_hr_printer.is_active()) {
- G1PrintCollectionSetClosure cl(&_hr_printer);
- _collection_set.iterate(&cl);
- }
+ if (_pause_succeeded) {
+ if (_word_size > 0) {
+ // An allocation had been requested. Do it, eventually trying a stronger
+ // kind of GC.
+ _result = g1h->satisfy_failed_allocation(_word_size, &_pause_succeeded);
+ } else {
+ bool should_upgrade_to_full = !g1h->should_do_concurrent_full_gc(_gc_cause) &&
+ !g1h->has_regions_left_for_allocation();
+ if (should_upgrade_to_full) {
+ // There has been a request to perform a GC to free some space. We have no
+ // information on how much memory has been asked for. In case there are
+ // absolutely no regions left to allocate into, do a maximally compacting full GC.
+ log_info(gc, ergo)("Attempting maximally compacting collection");
+ _pause_succeeded = g1h->do_full_collection(false, /* explicit gc */
+ true /* clear_all_soft_refs */);
+ }
+ }
+ guarantee(_pause_succeeded, "Elevated collections during the safepoint must always succeed.");
+ } else {
+ assert(_result == NULL, "invariant");
+ // The only reason for the pause to not be successful is that, the GC locker is
+ // active (or has become active since the prologue was executed). In this case
+ // we should retry the pause after waiting for the GC locker to become inactive.
+ _should_retry_gc = true;
+ }
+}
+这里可以看到核心的是G1CollectedHeap::do_collection_pause_at_safepoint这个方法，它带上了目标暂停时间的值
+G1CollectedHeap::do_collection_pause_at_safepoint(double target_pause_time_ms) {
+ assert_at_safepoint_on_vm_thread();
+ guarantee(!is_gc_active(), "collection is not reentrant");
- // Initialize the GC alloc regions.
- _allocator->init_gc_alloc_regions(evacuation_info);
+ if (GCLocker::check_active_before_gc()) {
+ return false;
+ }
- G1ParScanThreadStateSet per_thread_states(this, workers()->active_workers(), collection_set()->young_region_length());
- pre_evacuate_collection_set();
+ _gc_timer_stw->register_gc_start();
- // Actually do the work...
- evacuate_collection_set(&per_thread_states);
+ GCIdMark gc_id_mark;
+ _gc_tracer_stw->report_gc_start(gc_cause(), _gc_timer_stw->gc_start());
- post_evacuate_collection_set(evacuation_info, &per_thread_states);
+ SvcGCMarker sgcm(SvcGCMarker::MINOR);
+ ResourceMark rm;
- const size_t* surviving_young_words = per_thread_states.surviving_young_words();
- free_collection_set(&_collection_set, evacuation_info, surviving_young_words);
+ g1_policy()->note_gc_start();
- eagerly_reclaim_humongous_regions();
+ wait_for_root_region_scanning();
- record_obj_copy_mem_stats();
- _survivor_evac_stats.adjust_desired_plab_sz();
- _old_evac_stats.adjust_desired_plab_sz();
+ print_heap_before_gc();
+ print_heap_regions();
+ trace_heap_before_gc(_gc_tracer_stw);
+
+ _verifier->verify_region_sets_optional();
+ _verifier->verify_dirty_young_regions();
+
+ // We should not be doing initial mark unless the conc mark thread is running
+ if (!_cm_thread->should_terminate()) {
+ // This call will decide whether this pause is an initial-mark
+ // pause. If it is, in_initial_mark_gc() will return true
+ // for the duration of this pause.
+ g1_policy()->decide_on_conc_mark_initiation();
+ }
+
+ // We do not allow initial-mark to be piggy-backed on a mixed GC.
+ assert(!collector_state()->in_initial_mark_gc() ||
+ collector_state()->in_young_only_phase(), "sanity");
+
+ // We also do not allow mixed GCs during marking.
+ assert(!collector_state()->mark_or_rebuild_in_progress() || collector_state()->in_young_only_phase(), "sanity");
+
+ // Record whether this pause is an initial mark. When the current
+ // thread has completed its logging output and it's safe to signal
+ // the CM thread, the flag's value in the policy has been reset.
+ bool should_start_conc_mark = collector_state()->in_initial_mark_gc();
+
+ // Inner scope for scope based logging, timers, and stats collection
+ {
+ EvacuationInfo evacuation_info;
+
+ if (collector_state()->in_initial_mark_gc()) {
+ // We are about to start a marking cycle, so we increment the
+ // full collection counter.
+ increment_old_marking_cycles_started();
+ _cm->gc_tracer_cm()->set_gc_cause(gc_cause());
+ }
+
+ _gc_tracer_stw->report_yc_type(collector_state()->yc_type());
+
+ GCTraceCPUTime tcpu;
+
+ G1HeapVerifier::G1VerifyType verify_type;
+ FormatBuffer<> gc_string("Pause Young ");
+ if (collector_state()->in_initial_mark_gc()) {
+ gc_string.append("(Concurrent Start)");
+ verify_type = G1HeapVerifier::G1VerifyConcurrentStart;
+ } else if (collector_state()->in_young_only_phase()) {
+ if (collector_state()->in_young_gc_before_mixed()) {
+ gc_string.append("(Prepare Mixed)");
+ } else {
+ gc_string.append("(Normal)");
+ }
+ verify_type = G1HeapVerifier::G1VerifyYoungNormal;
+ } else {
+ gc_string.append("(Mixed)");
+ verify_type = G1HeapVerifier::G1VerifyMixed;
+ }
+ GCTraceTime(Info, gc) tm(gc_string, NULL, gc_cause(), true);
+
+ uint active_workers = AdaptiveSizePolicy::calc_active_workers(workers()->total_workers(),
+ workers()->active_workers(),
+ Threads::number_of_non_daemon_threads());
+ active_workers = workers()->update_active_workers(active_workers);
+ log_info(gc,task)("Using %u workers of %u for evacuation", active_workers, workers()->total_workers());
+
+ TraceCollectorStats tcs(g1mm()->incremental_collection_counters());
+ TraceMemoryManagerStats tms(&_memory_manager, gc_cause(),
+ collector_state()->yc_type() == Mixed /* allMemoryPoolsAffected */);
+
+ G1HeapTransition heap_transition(this);
+ size_t heap_used_bytes_before_gc = used();
+
+ // Don't dynamically change the number of GC threads this early. A value of
+ // 0 is used to indicate serial work. When parallel work is done,
+ // it will be set.
+
+ { // Call to jvmpi::post_class_unload_events must occur outside of active GC
+ IsGCActiveMark x;
+
+ gc_prologue(false);
+
+ if (VerifyRememberedSets) {
+ log_info(gc, verify)("[Verifying RemSets before GC]");
+ VerifyRegionRemSetClosure v_cl;
+ heap_region_iterate(&v_cl);
+ }
+
+ _verifier->verify_before_gc(verify_type);
+
+ _verifier->check_bitmaps("GC Start");
+
+#if COMPILER2_OR_JVMCI
+ DerivedPointerTable::clear();
+#endif
+
+ // Please see comment in g1CollectedHeap.hpp and
+ // G1CollectedHeap::ref_processing_init() to see how
+ // reference processing currently works in G1.
+
+ // Enable discovery in the STW reference processor
+ _ref_processor_stw->enable_discovery();
+
+ {
+ // We want to temporarily turn off discovery by the
+ // CM ref processor, if necessary, and turn it back on
+ // on again later if we do. Using a scoped
+ // NoRefDiscovery object will do this.
+ NoRefDiscovery no_cm_discovery(_ref_processor_cm);
+
+ // Forget the current alloc region (we might even choose it to be part
+ // of the collection set!).
+ _allocator->release_mutator_alloc_region();
+
+ // This timing is only used by the ergonomics to handle our pause target.
+ // It is unclear why this should not include the full pause. We will
+ // investigate this in CR 7178365.
+ //
+ // Preserving the old comment here if that helps the investigation:
+ //
+ // The elapsed time induced by the start time below deliberately elides
+ // the possible verification above.
+ double sample_start_time_sec = os::elapsedTime();
+
+ g1_policy()->record_collection_pause_start(sample_start_time_sec);
+
+ if (collector_state()->in_initial_mark_gc()) {
+ concurrent_mark()->pre_initial_mark();
+ }
+
+ g1_policy()->finalize_collection_set(target_pause_time_ms, &_survivor);
+
+ evacuation_info.set_collectionset_regions(collection_set()->region_length());
+
+ // Make sure the remembered sets are up to date. This needs to be
+ // done before register_humongous_regions_with_cset(), because the
+ // remembered sets are used there to choose eager reclaim candidates.
+ // If the remembered sets are not up to date we might miss some
+ // entries that need to be handled.
+ g1_rem_set()->cleanupHRRS();
+
+ register_humongous_regions_with_cset();
+
+ assert(_verifier->check_cset_fast_test(), "Inconsistency in the InCSetState table.");
+
+ // We call this after finalize_cset() to
+ // ensure that the CSet has been finalized.
+ _cm->verify_no_cset_oops();
+
+ if (_hr_printer.is_active()) {
+ G1PrintCollectionSetClosure cl(&_hr_printer);
+ _collection_set.iterate(&cl);
+ }
+
+ // Initialize the GC alloc regions.
+ _allocator->init_gc_alloc_regions(evacuation_info);
+
+ G1ParScanThreadStateSet per_thread_states(this, workers()->active_workers(), collection_set()->young_region_length());
+ pre_evacuate_collection_set();
+
+ // Actually do the work...
+ evacuate_collection_set(&per_thread_states);
+
+ post_evacuate_collection_set(evacuation_info, &per_thread_states);
+
+ const size_t* surviving_young_words = per_thread_states.surviving_young_words();
+ free_collection_set(&_collection_set, evacuation_info, surviving_young_words);
+
+ eagerly_reclaim_humongous_regions();
+
+ record_obj_copy_mem_stats();
+ _survivor_evac_stats.adjust_desired_plab_sz();
+ _old_evac_stats.adjust_desired_plab_sz();
double start = os::elapsedTime();
start_new_collection_set();
@@ -2470,78 +2670,6 @@ Node *clone(Node *graph) {
C++
-
- Leetcode 021 合并两个有序链表 ( Merge Two Sorted Lists ) 题解分析
- /2021/10/07/Leetcode-021-%E5%90%88%E5%B9%B6%E4%B8%A4%E4%B8%AA%E6%9C%89%E5%BA%8F%E9%93%BE%E8%A1%A8-Merge-Two-Sorted-Lists-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
- 题目介绍Merge two sorted linked lists and return it as a sorted list. The list should be made by splicing together the nodes of the first two lists.
-将两个升序链表合并为一个新的 升序 链表并返回。新链表是通过拼接给定的两个链表的所有节点组成的。
-示例 1
![]()
-
-输入：l1 = [1,2,4], l2 = [1,3,4]
输出：[1,1,2,3,4,4]
-
-示例 2
-输入: l1 = [], l2 = []
输出: []
-
-示例 3
-输入: l1 = [], l2 = [0]
输出: [0]
-
-简要分析
这题是 Easy 的，看着也挺简单，两个链表进行合并，就是比较下大小，可能将就点的话最好就在两个链表中原地合并
-题解代码
public ListNode mergeTwoLists(ListNode l1, ListNode l2) {
- // 下面两个if判断了入参的边界，如果其一为null，直接返回另一个就可以了
- if (l1 == null) {
- return l2;
- }
- if (l2 == null) {
- return l1;
- }
- // new 一个合并后的头结点
- ListNode merged = new ListNode();
- // 这个是当前节点
- ListNode current = merged;
- // 一开始给这个while加了l1和l2不全为null的条件，后面想了下不需要
- // 因为内部前两个if就是跳出条件
- while (true) {
- if (l1 == null) {
- // 这里其实跟开头类似，只不过这里需要将l2剩余部分接到merged链表后面
- // 所以不能是直接current = l2，这样就是把后面的直接丢了
- current.val = l2.val;
- current.next = l2.next;
- break;
- }
- if (l2 == null) {
- current.val = l1.val;
- current.next = l1.next;
- break;
- }
- // 这里是两个链表都不为空的时候，就比较下大小
- if (l1.val < l2.val) {
- current.val = l1.val;
- l1 = l1.next;
- } else {
- current.val = l2.val;
- l2 = l2.next;
- }
- // 这里是new个新的，其实也可以放在循环头上
- current.next = new ListNode();
- current = current.next;
- }
- current = null;
- // 返回这个头结点
- return merged;
- }
-
-结果
![]()
-]]>
-
- Java
- leetcode
-
-
- leetcode
- java
- 题解
-
-
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/
@@ -2701,10 +2829,10 @@ Output: 0
@@ -2764,9 +2892,9 @@ inorder = [9,3,15,20,7]
-
- 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
-
-
-
- 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 121 买卖股票的最佳时机(Best Time to Buy and Sell Stock) 题解分析
/2021/03/14/Leetcode-121-%E4%B9%B0%E5%8D%96%E8%82%A1%E7%A5%A8%E7%9A%84%E6%9C%80%E4%BD%B3%E6%97%B6%E6%9C%BA-Best-Time-to-Buy-and-Sell-Stock-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -2951,59 +2951,6 @@ inorder = [9,3,15,20,7]
-
- Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析
- /2021/01/24/Leetcode-124-%E4%BA%8C%E5%8F%89%E6%A0%91%E4%B8%AD%E7%9A%84%E6%9C%80%E5%A4%A7%E8%B7%AF%E5%BE%84%E5%92%8C-Binary-Tree-Maximum-Path-Sum-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
- 题目介绍A path in a binary tree is a sequence of nodes where each pair of adjacent nodes in the sequence has an edge connecting them. A node can only appear in the sequence at most once. Note that the path does not need to pass through the root.
-The path sum of a path is the sum of the node’s values in the path.
-Given the root of a binary tree, return the maximum path sum of any path.
-路径 被定义为一条从树中任意节点出发，沿父节点-子节点连接，达到任意节点的序列。该路径 至少包含一个 节点，且不一定经过根节点。
-路径和 是路径中各节点值的总和。
-给你一个二叉树的根节点 root ，返回其 最大路径和
-简要分析
其实这个题目会被误解成比较简单，左子树最大的，或者右子树最大的，或者两边加一下，仔细想想都不对，其实有可能是产生于左子树中，或者右子树中，这两个都是指跟左子树根还有右子树根没关系的，这么说感觉不太容易理解，画个图
![]()
可以看到图里，其实最长路径和是左边这个子树组成的，跟根节点还有右子树完全没关系，然后再想一种情况，如果是整棵树就是图中的左子树，那么这个最长路径和就是左子树加右子树加根节点了，所以不是我一开始想得那么简单，在代码实现中也需要一些技巧
-代码
int ansNew = Integer.MIN_VALUE;
-public int maxPathSum(TreeNode root) {
- maxSumNew(root);
- return ansNew;
- }
-
-public int maxSumNew(TreeNode root) {
- if (root == null) {
- return 0;
- }
- // 这里是个简单的递归，就是去递归左右子树，但是这里其实有个概念，当这样处理时，其实相当于把子树的内部的最大路径和已经算出来了
- int left = maxSumNew(root.left);
- int right = maxSumNew(root.right);
- // 这里前面我有点没想明白，但是看到 ansNew 的比较，其实相当于，返回的是三种情况里的最大值，一个是左子树+根，一个是右子树+根，一个是单独根节点，
- // 这样这个递归的返回才会有意义，不然像原来的方法，它可能是跳着的，但是这种情况其实是借助于 ansNew 这个全局的最大值，因为原来我觉得要比较的是
- // left, right, left + root , right + root, root, left + right + root 这些的最大值，这里是分成了两个阶段，left 跟 right 的最大值已经在上面的
- // 调用过程中赋值给 ansNew 了
- int currentSum = Math.max(Math.max(root.val + left , root.val + right), root.val);
- // 这边返回的是 currentSum，然后再用它跟 left + right + root 进行对比，然后再去更新 ans
- // PS: 有个小点也是这边的破局点，就是这个 ansNew
- int res = Math.max(left + right + root.val, currentSum);
- ans = Math.max(res, ans);
- return currentSum;
-}
-
-这里非常重要的就是 ansNew 是最后的一个结果，而对于 maxSumNew 这个函数的返回值其实是需要包含了一个连续结果，因为要返回继续去算路径和，所以返回的是 currentSum，最终结果是 ansNew
-结果图
难得有个 100%，贴个图哈哈
![]()
-]]>
-
- Java
- leetcode
- Binary Tree
- java
- Binary Tree
-
-
- leetcode
- java
- Binary Tree
- 二叉树
- 题解
-
-
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/
@@ -3091,6 +3038,59 @@ minStack.getMin(); // return -2
Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析
/2021/01/10/Leetcode-160-%E7%9B%B8%E4%BA%A4%E9%93%BE%E8%A1%A8-intersection-of-two-linked-lists-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -3156,64 +3156,8 @@ Input Explanation: The intersected node's value is 8 (note that this must no
leetcode
java
- 题解
- Linked List
-
-
-
- Leetcode 234 回文链表(Palindrome Linked List) 题解分析
- /2020/11/15/Leetcode-234-%E5%9B%9E%E6%96%87%E8%81%94%E8%A1%A8-Palindrome-Linked-List-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
- 题目介绍Given a singly linked list, determine if it is a palindrome.
给定一个单向链表，判断是否是回文链表
-例一 Example 1:
Input: 1->2
Output: false
-例二 Example 2:
Input: 1->2->2->1
Output: true
-挑战下自己
Follow up:
Could you do it in O(n) time and O(1) space?
-简要分析
首先这是个单向链表，如果是双向的就可以一个从头到尾，一个从尾到头，显然那样就没啥意思了，然后想过要不找到中点，然后用一个栈，把前一半塞进栈里，但是这种其实也比较麻烦，比如长度是奇偶数，然后如何找到中点，这倒是可以借助于双指针，还是比较麻烦，再想一想，回文链表，就跟最开始的一样，链表只有单向的，我用个栈不就可以逆向了么，先把链表整个塞进栈里，然后在一个个 pop 出来跟链表从头开始比较，全对上了就是回文了
-/**
- * Definition for singly-linked list.
- * public class ListNode {
- * int val;
- * ListNode next;
- * ListNode() {}
- * ListNode(int val) { this.val = val; }
- * ListNode(int val, ListNode next) { this.val = val; this.next = next; }
- * }
- */
-class Solution {
- public boolean isPalindrome(ListNode head) {
- if (head == null) {
- return true;
- }
- ListNode tail = head;
- LinkedList<Integer> stack = new LinkedList<>();
- // 这里就是一个循环，将所有元素依次压入栈
- while (tail != null) {
- stack.push(tail.val);
- tail = tail.next;
- }
- // 在逐个 pop 出来，其实这个出来的顺序就等于链表从尾到头遍历，同时跟链表从头到尾遍历进行逐对对比
- while (!stack.isEmpty()) {
- if (stack.peekFirst() == head.val) {
- stack.pollFirst();
- head = head.next;
- } else {
- return false;
- }
- }
- return true;
- }
-}
]]>
-
- Java
- leetcode
- Linked List
- java
- Linked List
-
-
- leetcode
- java
- 题解
Linked List
+ 题解
@@ -3277,6 +3221,62 @@ Output: [8,9,9,9,0,0,0,1]
+
+ Leetcode 234 回文链表(Palindrome Linked List) 题解分析
+ /2020/11/15/Leetcode-234-%E5%9B%9E%E6%96%87%E8%81%94%E8%A1%A8-Palindrome-Linked-List-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
+ 题目介绍Given a singly linked list, determine if it is a palindrome.
给定一个单向链表，判断是否是回文链表
+例一 Example 1:
Input: 1->2
Output: false
+例二 Example 2:
Input: 1->2->2->1
Output: true
+挑战下自己
Follow up:
Could you do it in O(n) time and O(1) space?
+简要分析
首先这是个单向链表，如果是双向的就可以一个从头到尾，一个从尾到头，显然那样就没啥意思了，然后想过要不找到中点，然后用一个栈，把前一半塞进栈里，但是这种其实也比较麻烦，比如长度是奇偶数，然后如何找到中点，这倒是可以借助于双指针，还是比较麻烦，再想一想，回文链表，就跟最开始的一样，链表只有单向的，我用个栈不就可以逆向了么，先把链表整个塞进栈里，然后在一个个 pop 出来跟链表从头开始比较，全对上了就是回文了
+/**
+ * Definition for singly-linked list.
+ * public class ListNode {
+ * int val;
+ * ListNode next;
+ * ListNode() {}
+ * ListNode(int val) { this.val = val; }
+ * ListNode(int val, ListNode next) { this.val = val; this.next = next; }
+ * }
+ */
+class Solution {
+ public boolean isPalindrome(ListNode head) {
+ if (head == null) {
+ return true;
+ }
+ ListNode tail = head;
+ LinkedList<Integer> stack = new LinkedList<>();
+ // 这里就是一个循环，将所有元素依次压入栈
+ while (tail != null) {
+ stack.push(tail.val);
+ tail = tail.next;
+ }
+ // 在逐个 pop 出来，其实这个出来的顺序就等于链表从尾到头遍历，同时跟链表从头到尾遍历进行逐对对比
+ while (!stack.isEmpty()) {
+ if (stack.peekFirst() == head.val) {
+ stack.pollFirst();
+ head = head.next;
+ } else {
+ return false;
+ }
+ }
+ return true;
+ }
+}
]]>
+
+ Java
+ leetcode
+ Linked List
+ java
+ Linked List
+
+
+ leetcode
+ java
+ Linked List
+ 题解
+
+
Leetcode 236 二叉树的最近公共祖先(Lowest Common Ancestor of a Binary Tree) 题解分析
/2021/05/23/Leetcode-236-%E4%BA%8C%E5%8F%89%E6%A0%91%E7%9A%84%E6%9C%80%E8%BF%91%E5%85%AC%E5%85%B1%E7%A5%96%E5%85%88-Lowest-Common-Ancestor-of-a-Binary-Tree-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -3325,6 +3325,72 @@ Output: [8,9,9,9,0,0,0,1]
+
+ Leetcode 349 两个数组的交集 ( Intersection of Two Arrays *Easy* ) 题解分析
+ /2022/03/07/Leetcode-349-%E4%B8%A4%E4%B8%AA%E6%95%B0%E7%BB%84%E7%9A%84%E4%BA%A4%E9%9B%86-Intersection-of-Two-Arrays-Easy-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
+ 题目介绍给定两个数组 nums1 和 nums2 ，返回 它们的交集 。输出结果中的每个元素一定是 唯一 的。我们可以 不考虑输出结果的顺序 。
+
+示例
+示例 1：
+输入：nums1 = [1,2,2,1], nums2 = [2,2]
输出：[2]
+
+
+示例 2：
+输入：nums1 = [4,9,5], nums2 = [9,4,9,8,4]
输出：[9,4]
解释：[4,9] 也是可通过的
+
+
+提示：
+1 <= nums1.length, nums2.length <= 10000 <= nums1[i], nums2[i] <= 1000
+分析与题解
两个数组的交集，最简单就是两层循环了把两个都存在的找出来，不过还有个要去重的问题，稍微思考下可以使用集合 set 来处理，先把一个数组全丢进去，再对比另外一个，如果出现在第一个集合里就丢进一个新的集合，最后转换成数组，这次我稍微取了个巧，因为看到了提示里的条件，两个数组中的元素都是不大于 1000 的，所以就搞了个 1000 长度的数组，如果在第一个数组出现，就在对应的下标设置成 1，如果在第二个数组也出现了就加 1，
+code
public int[] intersection(int[] nums1, int[] nums2) {
+ // 大小是 1000 的数组，如果没有提示的条件就没法这么做
+ // define a array which size is 1000, and can not be done like this without the condition in notice
+ int[] inter = new int[1000];
+ int[] outer;
+ int m = 0;
+ for (int j : nums1) {
+ // 这里得是设置成 1，因为有可能 nums1 就出现了重复元素，如果直接++会造成结果重复
+ // need to be set 1, cause element in nums1 can be duplicated
+ inter[j] = 1;
+ }
+ for (int j : nums2) {
+ if (inter[j] > 0) {
+ // 这里可以直接+1，因为后面判断只需要判断大于 1
+ // just plus 1, cause we can judge with condition that larger than 1
+ inter[j] += 1;
+ }
+ }
+ for (int i = 0; i < inter.length; i++) {
+ // 统计下元素数量
+ // count distinct elements
+ if (inter[i] > 1) {
+ m++;
+ }
+ }
+ // initial a array of size m
+ outer = new int[m];
+ m = 0;
+ for (int i = 0; i < inter.length; i++) {
+ if (inter[i] > 1) {
+ // add to outer
+ outer[m++] = i;
+ }
+ }
+ return outer;
+ }
]]>
+
+ Java
+ leetcode
+
+
+ leetcode
+ java
+ 题解
+ Intersection of Two Arrays
+
+
Leetcode 3 Longest Substring Without Repeating Characters 题解分析
/2020/09/20/Leetcode-3-Longest-Substring-Without-Repeating-Characters-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -3394,72 +3460,6 @@ Output: 0
-
- Leetcode 349 两个数组的交集 ( Intersection of Two Arrays *Easy* ) 题解分析
- /2022/03/07/Leetcode-349-%E4%B8%A4%E4%B8%AA%E6%95%B0%E7%BB%84%E7%9A%84%E4%BA%A4%E9%9B%86-Intersection-of-Two-Arrays-Easy-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
- 题目介绍给定两个数组 nums1 和 nums2 ，返回 它们的交集 。输出结果中的每个元素一定是 唯一 的。我们可以 不考虑输出结果的顺序 。
-
-示例
-示例 1：
-输入：nums1 = [1,2,2,1], nums2 = [2,2]
输出：[2]
-
-
-示例 2：
-输入：nums1 = [4,9,5], nums2 = [9,4,9,8,4]
输出：[9,4]
解释：[4,9] 也是可通过的
-
-
-提示：
-1 <= nums1.length, nums2.length <= 10000 <= nums1[i], nums2[i] <= 1000
-分析与题解
两个数组的交集，最简单就是两层循环了把两个都存在的找出来，不过还有个要去重的问题，稍微思考下可以使用集合 set 来处理，先把一个数组全丢进去，再对比另外一个，如果出现在第一个集合里就丢进一个新的集合，最后转换成数组，这次我稍微取了个巧，因为看到了提示里的条件，两个数组中的元素都是不大于 1000 的，所以就搞了个 1000 长度的数组，如果在第一个数组出现，就在对应的下标设置成 1，如果在第二个数组也出现了就加 1，
-code
public int[] intersection(int[] nums1, int[] nums2) {
- // 大小是 1000 的数组，如果没有提示的条件就没法这么做
- // define a array which size is 1000, and can not be done like this without the condition in notice
- int[] inter = new int[1000];
- int[] outer;
- int m = 0;
- for (int j : nums1) {
- // 这里得是设置成 1，因为有可能 nums1 就出现了重复元素，如果直接++会造成结果重复
- // need to be set 1, cause element in nums1 can be duplicated
- inter[j] = 1;
- }
- for (int j : nums2) {
- if (inter[j] > 0) {
- // 这里可以直接+1，因为后面判断只需要判断大于 1
- // just plus 1, cause we can judge with condition that larger than 1
- inter[j] += 1;
- }
- }
- for (int i = 0; i < inter.length; i++) {
- // 统计下元素数量
- // count distinct elements
- if (inter[i] > 1) {
- m++;
- }
- }
- // initial a array of size m
- outer = new int[m];
- m = 0;
- for (int i = 0; i < inter.length; i++) {
- if (inter[i] > 1) {
- // add to outer
- outer[m++] = i;
- }
- }
- return outer;
- }
]]>
-
- Java
- leetcode
-
-
- leetcode
- java
- 题解
- Intersection of Two Arrays
-
-
Leetcode 42 接雨水 (Trapping Rain Water) 题解分析
/2021/07/04/Leetcode-42-%E6%8E%A5%E9%9B%A8%E6%B0%B4-Trapping-Rain-Water-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -3592,6 +3592,34 @@ maxR[n -矩阵
+
+ leetcode no.3
+ /2015/04/15/Leetcode-No-3/
+ **Longest Substring Without Repeating Characters **
+
+description
Given a string, find the length of the longest substring without repeating characters.
For example, the longest substring without repeating letters for “abcabcbb” is “abc”,
which the length is 3. For “bbbbb” the longest substring is “b”, with the length of 1.
+分析
源码这次是参考了这个代码，
tail 表示的当前子串的起始点位置，tail从-1开始就包括的串的长度是1的边界。其实我
也是猜的（逃
+int ct[256];
+ memset(ct, -1, sizeof(ct));
+ int tail = -1;
+ int max = 0;
+ for (int i = 0; i < s.size(); i++){
+ if (ct[s[i]] > tail)
+ tail = ct[s[i]];
+ if (i - tail > max)
+ max = i - tail;
+ ct[s[i]] = i;
+ }
+ return max;
+]]>
+
+ leetcode
+
+
+ leetcode
+ c++
+
+
Leetcode 83 删除排序链表中的重复元素 ( Remove Duplicates from Sorted List *Easy* ) 题解分析
/2022/03/13/Leetcode-83-%E5%88%A0%E9%99%A4%E6%8E%92%E5%BA%8F%E9%93%BE%E8%A1%A8%E4%B8%AD%E7%9A%84%E9%87%8D%E5%A4%8D%E5%85%83%E7%B4%A0-Remove-Duplicates-from-Sorted-List-Easy-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
@@ -3631,7 +3659,7 @@ maxR[n -// 最后返回头结点
return head;
}
-链表应该是个需要反复的训练的数据结构，因为涉及到前后指针，然后更新操作，判空等，
我在这块也是掌握的不太好，需要多联系
+链表应该是个需要反复的训练的数据结构，因为涉及到前后指针，然后更新操作，判空等，
我在这块也是掌握的不太好，需要多练习。
]]>
Java
@@ -3645,31 +3673,24 @@ maxR[n -
- leetcode no.3
- /2015/04/15/Leetcode-No-3/
- **Longest Substring Without Repeating Characters **
-
-description
Given a string, find the length of the longest substring without repeating characters.
For example, the longest substring without repeating letters for “abcabcbb” is “abc”,
which the length is 3. For “bbbbb” the longest substring is “b”, with the length of 1.
-分析
源码这次是参考了这个代码，
tail 表示的当前子串的起始点位置，tail从-1开始就包括的串的长度是1的边界。其实我
也是猜的（逃
-int ct[256];
- memset(ct, -1, sizeof(ct));
- int tail = -1;
- int max = 0;
- for (int i = 0; i < s.size(); i++){
- if (ct[s[i]] > tail)
- tail = ct[s[i]];
- if (i - tail > max)
- max = i - tail;
- ct[s[i]] = i;
- }
- return max;
+ MFC 模态对话框
+ /2014/12/24/MFC%20%E6%A8%A1%E6%80%81%E5%AF%B9%E8%AF%9D%E6%A1%86/
+ void CTestDialog::OnBnClickedOk()
+{
+ CString m_SrcTest;
+ int nIndex = m_CbTest.GetCurSel();
+ m_CbTest.GetLBText(nIndex, m_SrcTest);
+ OnOK();
+}
+
+模态对话框弹出确定后，在弹出对话框时新建的类及其变量会存在，但是对于其中的控件
对象无法调用函数，即如果要在主对话框中获得弹出对话框的Combo box选中值的话，需
要在弹出 对话框的确定函数内将其值取出，赋值给弹出对话框的公有变量，这样就可以
在主对话框类得到值。
]]>
- leetcode
+ C++
- leetcode
c++
+ mfc
@@ -3694,9 +3715,9 @@ grep '\"userId\":\"123456\"' xxxx.log
]]>
Linux
- 小技巧
命令
grep
+ 小技巧
grep
查日志
@@ -3706,27 +3727,6 @@ grep '\"userId\":\"123456\"' xxxx.log
转义
-
- MFC 模态对话框
- /2014/12/24/MFC%20%E6%A8%A1%E6%80%81%E5%AF%B9%E8%AF%9D%E6%A1%86/
- void CTestDialog::OnBnClickedOk()
-{
- CString m_SrcTest;
- int nIndex = m_CbTest.GetCurSel();
- m_CbTest.GetLBText(nIndex, m_SrcTest);
- OnOK();
-}
-
-模态对话框弹出确定后，在弹出对话框时新建的类及其变量会存在，但是对于其中的控件
对象无法调用函数，即如果要在主对话框中获得弹出对话框的Combo box选中值的话，需
要在弹出 对话框的确定函数内将其值取出，赋值给弹出对话框的公有变量，这样就可以
在主对话框类得到值。
-]]>
- C++
-
-
- c++
- mfc
-
-
Maven实用小技巧
/2020/02/16/Maven%E5%AE%9E%E7%94%A8%E5%B0%8F%E6%8A%80%E5%B7%A7/
@@ -3835,6 +3835,45 @@ OS name: "mac os x", version: "10.14.6", arch: "x86_64&
c++
+
+ Redis_分布式锁
+ /2019/12/10/Redis-Part-1/
+ 今天看了一下 redis 分布式锁 redlock 的实现，简单记录下，
+加锁
原先我对 redis 锁的概念就是加锁使用 setnx，解锁使用 lua 脚本，但是 setnx 具体是啥，lua 脚本是啥不是很清楚
首先简单思考下这个问题，首先为啥不是先 get 一下 key 存不存在，然后再 set 一个 key value，因为加锁这个操作我们是要保证两点，一个是不能中途被打断，也就是说要原子性，如果是先 get 一下 key，如果不存在再 set 值的话，那就不是原子操作了；第二个是可不可以直接 set 值呢，显然不行，锁要保证唯一性，有且只能有一个线程或者其他应用单位获得该锁，正好 setnx 给了我们这种原子命令
+然后是 setnx 的键和值分别是啥，键比较容易想到是要锁住的资源，比如 user_id, 这里有个我自己之前比较容易陷进去的误区，但是这个误区后
面再说，这里其实是把user_id 作为要锁住的资源，在我获得锁的时候别的线程不允许操作，以此保证业务的正确性，不会被多个线程同时修改，确定了键，再来看看值是啥，其实原先我认为值是啥都没关系，我只要锁住了，光键就够我用了，但是考虑下多个线程的问题，如果我这个线程加了锁，然后我因为 gc 停顿等原因卡死了，这个时候redis 的锁或者说就是 redis 的缓存已经过期了，这时候另一个线程获得锁成功，然后我这个线程又活过来了，然后我就仍然认为我拿着锁，我去对数据进行修改或者释放锁，是不是就出现问题了，所以是不是我们还需要一个东西来区分这个锁是哪个线程加的，所以我们可以将值设置成为一个线程独有识别的值，至少在相对长的一段时间内不会重复。
+上面其实还有两个问题，一个是当 gc 超时时，我这个线程如何知道我手里的锁已经过期了，一种方法是我在加好锁之后就维护一个超时时间，这里其实还有个问题，不过跟第二个问题相关，就一起说了，就是设置超时时间，有些对于不是锁的 redis 缓存操作可以是先设置好值，然后在设置过期时间，那么这就又有上面说到的不是原子性的问题，那么就需要在同一条指令里把超时时间也设置了，幸好 redis 提供了这种支持
+SET resource_name my_random_value NX PX 30000
+这里借鉴一下解释下，resource_name就是 key，代表要锁住的东西，my_random_value就是识别我这个线程的，NX代表只有在不存在的时候才设置，然后PX 30000表示超时时间是 30秒自动过期
+PS：记录下我原先有的一个误区，是不是要用 key 来区分加锁的线程，这样只有一个用处，就是自身线程可以识别是否是自己加的锁，但是最大的问题是别的线程不知道，其实这个用户的出发点是我在担心前面提过的一个问题，就是当 gc 停顿后，我要去判断当前的这个锁是否是我加的，还有就是当释放锁的时候，如果保证不会错误释放了其他线程加的锁，但是这样附带很多其他问题，最大的就是其他线程怎么知道能不能加这个锁。
+解锁
当线程在锁过期之前就处理完了业务逻辑，那就可以提前释放这个锁，那么提前释放要怎么操作，直接del key显然是不行的，因为这样就是我前面想用线程随机值加资源名作为锁的初衷，我不能去释放别的线程加的锁，那么我要怎么办呢，先 get 一下看是不是我的？那又变成非原子的操作了，幸好redis 也考虑到了这个问题，给了lua 脚本来操作这种
+if redis.call("get",KEYS[1]) == ARGV[1] then
+ return redis.call("del",KEYS[1])
+else
+ return 0
+end
+这里的KEYS[1]就是前面加锁的resource_name,ARGV[1]就是线程的随机值my_random_value
+多节点
前面说的其实是单节点 redis 作为分布式锁的情况，那么当我们的 redis 有多节点的情况呢，如果多节点下处于加锁或者解锁或者锁有效情况下
redis 的某个节点宕掉了怎么办，这里就有一些需要思考的地方，是否单独搞一个单节点的 redis作为分布式锁专用的，但是如果这个单节点的挂了呢，还有就是成本问题，所以我们需要一个多节点的分布式锁方案
这里就引出了开头说到的redlock，这个可是 redis的作者写的, 他的加锁过程是分以下几步去做这个事情
+
+- 获取当前时间（毫秒数）。
+- 按顺序依次向N个Redis节点执行获取锁的操作。这个获取操作跟前面基于单Redis节点的获取锁的过程相同，包含随机字符串my_random_value，也包含过期时间(比如PX 30000，即锁的有效时间)。为了保证在某个Redis节点不可用的时候算法能够继续运行，这个获取锁的操作还有一个超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个Redis节点获取锁失败以后，应该立即尝试下一个Redis节点。这里的失败，应该包含任何类型的失败，比如该Redis节点不可用，或者该Redis节点上的锁已经被其它客户端持有（注：Redlock原文中这里只提到了Redis节点不可用的情况，但也应该包含其它的失败情况）。
+- 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数Redis节点（>= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间(lock validity time)，那么这时客户端才认为最终获取锁成功；否则，认为最终获取锁失败。
+- 如果最终获取锁成功了，那么这个锁的有效时间应该重新计算，它等于最初的锁的有效时间减去第3步计算出来的获取锁消耗的时间。
+- 如果最终获取锁失败了（可能由于获取到锁的Redis节点个数少于N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端应该立即向所有Redis节点发起释放锁的操作（即前面介绍的Redis Lua脚本）。
释放锁的过程比较简单：客户端向所有Redis节点发起释放锁的操作，不管这些节点当时在获取锁的时候成功与否。这里为什么要向所有的节点发送释放锁的操作呢，这里是因为有部分的节点的失败原因可能是加锁时阻塞，加锁成功的结果没有及时返回，所以为了防止这种情况还是需要向所有发起这个释放锁的操作。
初步记录就先到这。
+
+]]>
+
+ Redis
+ Distributed Lock
+ C
+ Redis
+
+
+ C
+ Redis
+ Distributed Lock
+ 分布式锁
+
+
Path Sum
/2015/01/04/Path-Sum/
@@ -3887,45 +3926,6 @@ public:
c++
-
- Redis_分布式锁
- /2019/12/10/Redis-Part-1/
- 今天看了一下 redis 分布式锁 redlock 的实现，简单记录下，
-加锁
原先我对 redis 锁的概念就是加锁使用 setnx，解锁使用 lua 脚本，但是 setnx 具体是啥，lua 脚本是啥不是很清楚
首先简单思考下这个问题，首先为啥不是先 get 一下 key 存不存在，然后再 set 一个 key value，因为加锁这个操作我们是要保证两点，一个是不能中途被打断，也就是说要原子性，如果是先 get 一下 key，如果不存在再 set 值的话，那就不是原子操作了；第二个是可不可以直接 set 值呢，显然不行，锁要保证唯一性，有且只能有一个线程或者其他应用单位获得该锁，正好 setnx 给了我们这种原子命令
-然后是 setnx 的键和值分别是啥，键比较容易想到是要锁住的资源，比如 user_id, 这里有个我自己之前比较容易陷进去的误区，但是这个误区后
面再说，这里其实是把user_id 作为要锁住的资源，在我获得锁的时候别的线程不允许操作，以此保证业务的正确性，不会被多个线程同时修改，确定了键，再来看看值是啥，其实原先我认为值是啥都没关系，我只要锁住了，光键就够我用了，但是考虑下多个线程的问题，如果我这个线程加了锁，然后我因为 gc 停顿等原因卡死了，这个时候redis 的锁或者说就是 redis 的缓存已经过期了，这时候另一个线程获得锁成功，然后我这个线程又活过来了，然后我就仍然认为我拿着锁，我去对数据进行修改或者释放锁，是不是就出现问题了，所以是不是我们还需要一个东西来区分这个锁是哪个线程加的，所以我们可以将值设置成为一个线程独有识别的值，至少在相对长的一段时间内不会重复。
-上面其实还有两个问题，一个是当 gc 超时时，我这个线程如何知道我手里的锁已经过期了，一种方法是我在加好锁之后就维护一个超时时间，这里其实还有个问题，不过跟第二个问题相关，就一起说了，就是设置超时时间，有些对于不是锁的 redis 缓存操作可以是先设置好值，然后在设置过期时间，那么这就又有上面说到的不是原子性的问题，那么就需要在同一条指令里把超时时间也设置了，幸好 redis 提供了这种支持
-SET resource_name my_random_value NX PX 30000
-这里借鉴一下解释下，resource_name就是 key，代表要锁住的东西，my_random_value就是识别我这个线程的，NX代表只有在不存在的时候才设置，然后PX 30000表示超时时间是 30秒自动过期
-PS：记录下我原先有的一个误区，是不是要用 key 来区分加锁的线程，这样只有一个用处，就是自身线程可以识别是否是自己加的锁，但是最大的问题是别的线程不知道，其实这个用户的出发点是我在担心前面提过的一个问题，就是当 gc 停顿后，我要去判断当前的这个锁是否是我加的，还有就是当释放锁的时候，如果保证不会错误释放了其他线程加的锁，但是这样附带很多其他问题，最大的就是其他线程怎么知道能不能加这个锁。
-解锁
当线程在锁过期之前就处理完了业务逻辑，那就可以提前释放这个锁，那么提前释放要怎么操作，直接del key显然是不行的，因为这样就是我前面想用线程随机值加资源名作为锁的初衷，我不能去释放别的线程加的锁，那么我要怎么办呢，先 get 一下看是不是我的？那又变成非原子的操作了，幸好redis 也考虑到了这个问题，给了lua 脚本来操作这种
-if redis.call("get",KEYS[1]) == ARGV[1] then
- return redis.call("del",KEYS[1])
-else
- return 0
-end
-这里的KEYS[1]就是前面加锁的resource_name,ARGV[1]就是线程的随机值my_random_value
-多节点
前面说的其实是单节点 redis 作为分布式锁的情况，那么当我们的 redis 有多节点的情况呢，如果多节点下处于加锁或者解锁或者锁有效情况下
redis 的某个节点宕掉了怎么办，这里就有一些需要思考的地方，是否单独搞一个单节点的 redis作为分布式锁专用的，但是如果这个单节点的挂了呢，还有就是成本问题，所以我们需要一个多节点的分布式锁方案
这里就引出了开头说到的redlock，这个可是 redis的作者写的, 他的加锁过程是分以下几步去做这个事情
-
-- 获取当前时间（毫秒数）。
-- 按顺序依次向N个Redis节点执行获取锁的操作。这个获取操作跟前面基于单Redis节点的获取锁的过程相同，包含随机字符串my_random_value，也包含过期时间(比如PX 30000，即锁的有效时间)。为了保证在某个Redis节点不可用的时候算法能够继续运行，这个获取锁的操作还有一个超时时间(time out)，它要远小于锁的有效时间（几十毫秒量级）。客户端在向某个Redis节点获取锁失败以后，应该立即尝试下一个Redis节点。这里的失败，应该包含任何类型的失败，比如该Redis节点不可用，或者该Redis节点上的锁已经被其它客户端持有（注：Redlock原文中这里只提到了Redis节点不可用的情况，但也应该包含其它的失败情况）。
-- 计算整个获取锁的过程总共消耗了多长时间，计算方法是用当前时间减去第1步记录的时间。如果客户端从大多数Redis节点（>= N/2+1）成功获取到了锁，并且获取锁总共消耗的时间没有超过锁的有效时间(lock validity time)，那么这时客户端才认为最终获取锁成功；否则，认为最终获取锁失败。
-- 如果最终获取锁成功了，那么这个锁的有效时间应该重新计算，它等于最初的锁的有效时间减去第3步计算出来的获取锁消耗的时间。
-- 如果最终获取锁失败了（可能由于获取到锁的Redis节点个数少于N/2+1，或者整个获取锁的过程消耗的时间超过了锁的最初有效时间），那么客户端应该立即向所有Redis节点发起释放锁的操作（即前面介绍的Redis Lua脚本）。
释放锁的过程比较简单：客户端向所有Redis节点发起释放锁的操作，不管这些节点当时在获取锁的时候成功与否。这里为什么要向所有的节点发送释放锁的操作呢，这里是因为有部分的节点的失败原因可能是加锁时阻塞，加锁成功的结果没有及时返回，所以为了防止这种情况还是需要向所有发起这个释放锁的操作。
初步记录就先到这。
-
-]]>
-
- Redis
- Distributed Lock
- C
- Redis
-
-
- C
- Redis
- Distributed Lock
- 分布式锁
-
-
Reverse Bits
/2015/03/11/Reverse-Bits/
@@ -3944,50 +3944,6 @@ public:
return n;
}
};
-]]>
-
- leetcode
-
-
- leetcode
- c++
-
-
-
- Reverse Integer
- /2015/03/13/Reverse-Integer/
- Reverse IntegerReverse digits of an integer.
Example1: x = 123, return 321
Example2: x = -123, return -321
-
-spoilers
Have you thought about this?
Here are some good questions to ask before coding. Bonus points for you if you have already thought through this!
-If the integer’s last digit is 0, what should the output be? ie, cases such as 10, 100.
-Did you notice that the reversed integer might overflow? Assume the input is a 32-bit integer, then the reverse of 1000000003 overflows. How should you handle such cases?
-For the purpose of this problem, assume that your function returns 0 when the reversed integer overflows.
-
-code
class Solution {
-public:
- int reverse(int x) {
-
- int max = 1 << 31 - 1;
- int ret = 0;
- max = (max - 1) * 2 + 1;
- int min = 1 << 31;
- if(x < 0)
- while(x != 0){
- if(ret < (min - x % 10) / 10)
- return 0;
- ret = ret * 10 + x % 10;
- x = x / 10;
- }
- else
- while(x != 0){
- if(ret > (max -x % 10) / 10)
- return 0;
- ret = ret * 10 + x % 10;
- x = x / 10;
- }
- return ret;
- }
-};
]]>
leetcode
@@ -4067,22 +4023,47 @@ public:
- ambari-summary
- /2017/05/09/ambari-summary/
- 初识ambariambari是一个大数据平台的管理工具，包含了hadoop, yarn, hive, hbase, spark等大数据的基础架构和工具，简化了数据平台的搭建，之前只是在同事搭建好平台后的一些使用，这次有机会从头开始用ambari来搭建一个测试的数据平台，过程中也踩到不少坑，简单记录下。
-简单过程
-- 第一个坑
在刚开始是按照官网的指南，用maven构建，因为GFW的原因，导致反复失败等待，也就是这个guide，因为对maven不熟悉导致有些按图索骥，浪费了很多时间，之后才知道可以直接加repo用yum安装，然而用yum安装马上就出现了第二个坑。
-- 第二个坑
因为在线的repo还是因为网络原因很慢很慢，用proxychains勉强把ambari-server本身安装好了，ambari.repo将这个放进/etc/yum.repos.d/路径下，然后yum update && yum install ambari-server安装即可，如果有条件就用proxychains走下代理。
-- 第三步
安装好ambari-server后先执行ambari-server setup做一些初始化设置，其中包含了JDK路径的设置，数据库设置，设置好就OK了，然后执行ambari-server start启动服务，这里有个小插曲，因为ambari-server涉及到这么多服务，所以管理控制监控之类的模块是必不可少的，这部分可以在ambari-server的web ui界面安装，也可以命令行提前安装，这部分被称为HDF Management Pack，运行```ambari-server install-mpack \
-
-–mpack=http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz
–purge
–verbose```
安装，当然这个压缩包可以下载之后指到本地路径安装，然后就可以重启ambari-server
+ Reverse Integer
+ /2015/03/13/Reverse-Integer/
+ Reverse IntegerReverse digits of an integer.
Example1: x = 123, return 321
Example2: x = -123, return -321
+
+spoilers
Have you thought about this?
Here are some good questions to ask before coding. Bonus points for you if you have already thought through this!
+If the integer’s last digit is 0, what should the output be? ie, cases such as 10, 100.
+Did you notice that the reversed integer might overflow? Assume the input is a 32-bit integer, then the reverse of 1000000003 overflows. How should you handle such cases?
+For the purpose of this problem, assume that your function returns 0 when the reversed integer overflows.
+
+code
class Solution {
+public:
+ int reverse(int x) {
+
+ int max = 1 << 31 - 1;
+ int ret = 0;
+ max = (max - 1) * 2 + 1;
+ int min = 1 << 31;
+ if(x < 0)
+ while(x != 0){
+ if(ret < (min - x % 10) / 10)
+ return 0;
+ ret = ret * 10 + x % 10;
+ x = x / 10;
+ }
+ else
+ while(x != 0){
+ if(ret > (max -x % 10) / 10)
+ return 0;
+ ret = ret * 10 + x % 10;
+ x = x / 10;
+ }
+ return ret;
+ }
+};
]]>
- data analysis
+ leetcode
- hadoop
- cluster
+ leetcode
+ c++
@@ -4150,6 +4131,25 @@ master_port=3306; //如果是同一宿主机
mysql
+
+ ambari-summary
+ /2017/05/09/ambari-summary/
+ 初识ambariambari是一个大数据平台的管理工具，包含了hadoop, yarn, hive, hbase, spark等大数据的基础架构和工具，简化了数据平台的搭建，之前只是在同事搭建好平台后的一些使用，这次有机会从头开始用ambari来搭建一个测试的数据平台，过程中也踩到不少坑，简单记录下。
+简单过程
+- 第一个坑
在刚开始是按照官网的指南，用maven构建，因为GFW的原因，导致反复失败等待，也就是这个guide，因为对maven不熟悉导致有些按图索骥，浪费了很多时间，之后才知道可以直接加repo用yum安装，然而用yum安装马上就出现了第二个坑。
+- 第二个坑
因为在线的repo还是因为网络原因很慢很慢，用proxychains勉强把ambari-server本身安装好了，ambari.repo将这个放进/etc/yum.repos.d/路径下，然后yum update && yum install ambari-server安装即可，如果有条件就用proxychains走下代理。
+- 第三步
安装好ambari-server后先执行ambari-server setup做一些初始化设置，其中包含了JDK路径的设置，数据库设置，设置好就OK了，然后执行ambari-server start启动服务，这里有个小插曲，因为ambari-server涉及到这么多服务，所以管理控制监控之类的模块是必不可少的，这部分可以在ambari-server的web ui界面安装，也可以命令行提前安装，这部分被称为HDF Management Pack，运行```ambari-server install-mpack \
+
+–mpack=http://public-repo-1.hortonworks.com/HDF/centos7/2.x/updates/2.1.4.0/tars/hdf_ambari_mp/hdf-ambari-mpack-2.1.4.0-5.tar.gz
–purge
–verbose```
安装，当然这个压缩包可以下载之后指到本地路径安装，然后就可以重启ambari-server
+]]>
+
+ data analysis
+
+
+ hadoop
+ cluster
+
+
docker比一般多一点的初学者介绍
/2020/03/08/docker%E6%AF%94%E4%B8%80%E8%88%AC%E5%A4%9A%E4%B8%80%E7%82%B9%E7%9A%84%E5%88%9D%E5%AD%A6%E8%80%85%E4%BB%8B%E7%BB%8D/
@@ -4242,6 +4242,26 @@ EXPOSE 80
+
+ docker使用中发现的echo命令的一个小技巧及其他
+ /2020/03/29/echo%E5%91%BD%E4%BB%A4%E7%9A%84%E4%B8%80%E4%B8%AA%E5%B0%8F%E6%8A%80%E5%B7%A7/
+ 最近做 docker 系列，会经常进到 docker 内部，如上一篇介绍的，这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包，如果构建镜像的时候没有替换源的话，因为你懂的原因，在内部想编辑下东西要安装 vim 就会很慢很慢，thousand years later~
而且如果在容器内部想改源配置的话也要编辑器，就陷入了一个鸡生蛋，跟蛋生鸡的问题中，对于 linux 大神来说应该有一万种方法解决这个问题，对于我这个渣渣来说可能只想到了这个土方法，先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题，这个 sources.list 一般不止一行，直接 echo 的话就解析不了了，不过 echo 可以支持”\n”转义，就是加-e
看一下解释和示例
![]()
还有一点也是在这个时候要安装 vim 之类的，得知道是什么镜像底包，如果是用 uname 指令，其实看到的是宿主机的系统，得用cat /etc/issue
![]()
这里稍稍记一下
+]]>
+
+ Linux
+ 命令
+ Docker
+ echo
+ 发行版本
+
+
+ linux
+ Docker
+ echo
+ uname
+ 发行版
+
+
docker比一般多一点的初学者介绍二
/2020/03/15/docker%E6%AF%94%E4%B8%80%E8%88%AC%E5%A4%9A%E4%B8%80%E7%82%B9%E7%9A%84%E5%88%9D%E5%AD%A6%E8%80%85%E4%BB%8B%E7%BB%8D%E4%BA%8C/
@@ -4283,23 +4303,52 @@ EXPOSE 80
- docker使用中发现的echo命令的一个小技巧及其他
- /2020/03/29/echo%E5%91%BD%E4%BB%A4%E7%9A%84%E4%B8%80%E4%B8%AA%E5%B0%8F%E6%8A%80%E5%B7%A7/
- 最近做 docker 系列，会经常进到 docker 内部，如上一篇介绍的，这些镜像一般都有用 ubuntu 或者alpine 这样的 Linux 系统作为底包，如果构建镜像的时候没有替换源的话，因为你懂的原因，在内部想编辑下东西要安装 vim 就会很慢很慢，thousand years later~
而且如果在容器内部想改源配置的话也要编辑器，就陷入了一个鸡生蛋，跟蛋生鸡的问题中，对于 linux 大神来说应该有一万种方法解决这个问题，对于我这个渣渣来说可能只想到了这个土方法，先 cp backup 一下 sources.list, 再 echo “xxx” > sources.list, 这里就碰到了一个问题，这个 sources.list 一般不止一行，直接 echo 的话就解析不了了，不过 echo 可以支持”\n”转义，就是加-e
看一下解释和示例
![]()
还有一点也是在这个时候要安装 vim 之类的，得知道是什么镜像底包，如果是用 uname 指令，其实看到的是宿主机的系统，得用cat /etc/issue
![]()
这里稍稍记一下
-]]>
+ invert-binary-tree
+ /2015/06/22/invert-binary-tree/
+ Invert a binary tree
+ 4
+ / \
+ 2 7
+ / \ / \
+1 3 6 9
+
+to
+ 4
+ / \
+ 7 2
+ / \ / \
+9 6 3 1
+
+Trivia:
This problem was inspired by this original tweet by Max Howell:
+
+Google: 90% of our engineers use the software you wrote (Homebrew),
but you can’t invert a binary tree on a whiteboard so fuck off.
+
+/**
+ * Definition for a binary tree node.
+ * struct TreeNode {
+ * int val;
+ * TreeNode *left;
+ * TreeNode *right;
+ * TreeNode(int x) : val(x), left(NULL), right(NULL) {}
+ * };
+ */
+class Solution {
+public:
+ TreeNode* invertTree(TreeNode* root) {
+ if(root == NULL) return root;
+ TreeNode* temp;
+ temp = invertTree(root->left);
+ root->left = invertTree(root->right);
+ root->right = temp;
+ return root;
+ }
+};
]]>
- Linux
- Docker
- 命令
- echo
- 发行版本
+ leetcode
- linux
- Docker
- echo
- uname
- 发行版
+ leetcode
+ c++
@@ -4401,55 +4450,6 @@ myusername ALL = (root) NOPASSWD: /path/to/my/programWebhook
-
- invert-binary-tree
- /2015/06/22/invert-binary-tree/
- Invert a binary tree
- 4
- / \
- 2 7
- / \ / \
-1 3 6 9
-
-to
- 4
- / \
- 7 2
- / \ / \
-9 6 3 1
-
-Trivia:
This problem was inspired by this original tweet by Max Howell:
-
-Google: 90% of our engineers use the software you wrote (Homebrew),
but you can’t invert a binary tree on a whiteboard so fuck off.
-
-/**
- * Definition for a binary tree node.
- * struct TreeNode {
- * int val;
- * TreeNode *left;
- * TreeNode *right;
- * TreeNode(int x) : val(x), left(NULL), right(NULL) {}
- * };
- */
-class Solution {
-public:
- TreeNode* invertTree(TreeNode* root) {
- if(root == NULL) return root;
- TreeNode* temp;
- temp = invertTree(root->left);
- root->left = invertTree(root->right);
- root->right = temp;
- return root;
- }
-};
]]>
-
- leetcode
-
-
- leetcode
- c++
-
-
minimum-size-subarray-sum-209
/2016/10/11/minimum-size-subarray-sum-209/
@@ -4583,8 +4583,8 @@ public class DynamicSqlSource implements SqlSource {
]]>
Java
- Mybatis
Spring
+ Mybatis
Mysql
Sql注入
Mybatis
@@ -4827,9 +4827,9 @@ public class DynamicSqlSource implements SqlSource {
}]]>
Java
- Mybatis
Spring
Mybatis
+ Mybatis
缓存
Mybatis
@@ -5213,68 +5213,6 @@ int zslRandomLevel(void) {
return (level<ZSKIPLIST_MAXLEVEL) ? level : ZSKIPLIST_MAXLEVEL;
}
当随机值跟0xFFFF进行与操作小于ZSKIPLIST_P * 0xFFFF时才会增大 level 的值，因此保持了一个相对递减的概率
可以简单分析下，当 random() 的值小于 0xFFFF 的 1/4,才会 level + 1，就意味着当有 1 - 1/4也就是3/4的概率是直接跳出，所以一层的概率是3/4,也就是 1-P，二层的概率是 P*(1-P),三层的概率是 P² * (1-P) 依次递推。
-]]>
-
- Redis
- 数据结构
- C
- 源码
- Redis
-
-
- redis
- 数据结构
- 源码
-
-
-
- redis数据结构介绍五-第五部分 对象
- /2020/01/20/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%BA%94/
- 前面说了这么些数据结构，其实大家对于 redis 最初的印象应该就是个 key-value 的缓存，类似于 memcache，redis 其实也是个 key-value，key 还是一样的字符串，或者说就是用 redis 自己的动态字符串实现，但是 value 其实就是前面说的那些数据结构，差不多快说完了，还有个 quicklist 后面还有一篇，这里先介绍下 redis 对于这些不同类型的 value 是怎么实现的，首先看下 redisObject 的源码头文件
-/* The actual Redis Object */
-#define OBJ_STRING 0 /* String object. */
-#define OBJ_LIST 1 /* List object. */
-#define OBJ_SET 2 /* Set object. */
-#define OBJ_ZSET 3 /* Sorted set object. */
-#define OBJ_HASH 4 /* Hash object. */
-/*
- * Objects encoding. Some kind of objects like Strings and Hashes can be
- * internally represented in multiple ways. The 'encoding' field of the object
- * is set to one of this fields for this object. */
-#define OBJ_ENCODING_RAW 0 /* Raw representation */
-#define OBJ_ENCODING_INT 1 /* Encoded as integer */
-#define OBJ_ENCODING_HT 2 /* Encoded as hash table */
-#define OBJ_ENCODING_ZIPMAP 3 /* Encoded as zipmap */
-#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old list encoding. */
-#define OBJ_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
-#define OBJ_ENCODING_INTSET 6 /* Encoded as intset */
-#define OBJ_ENCODING_SKIPLIST 7 /* Encoded as skiplist */
-#define OBJ_ENCODING_EMBSTR 8 /* Embedded sds string encoding */
-#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list of ziplists */
-#define OBJ_ENCODING_STREAM 10 /* Encoded as a radix tree of listpacks */
-
-#define LRU_BITS 24
-#define LRU_CLOCK_MAX ((1<<LRU_BITS)-1) /* Max value of obj->lru */
-#define LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
-
-#define OBJ_SHARED_REFCOUNT INT_MAX
-typedef struct redisObject {
- unsigned type:4;
- unsigned encoding:4;
- unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
- * LFU data (least significant 8 bits frequency
- * and most significant 16 bits access time). */
- int refcount;
- void *ptr;
-} robj;
-主体结构就是这个 redisObject，
-
-- type： 字段表示对象的类型，它对应的就是 redis 的对外暴露的，或者说用户可以使用的五种类型，OBJ_STRING, OBJ_LIST, OBJ_SET, OBJ_ZSET, OBJ_HASH
-- encoding： 字段表示这个对象在 redis 内部的编码方式，由OBJ_ENCODING_开头的 11 种
-- lru: 做LRU替换算法用，占24个bit
-- refcount: 引用计数。它允许robj对象在某些情况下被共享。
-- ptr: 指向底层实现数据结构的指针
当 type 是 OBJ_STRING 时，表示类型是个 string，它的编码方式 encoding 可能有 OBJ_ENCODING_RAW，OBJ_ENCODING_INT，OBJ_ENCODING_EMBSTR 三种
当 type 是 OBJ_LIST 时，表示类型是 list，它的编码方式 encoding 是 OBJ_ENCODING_QUICKLIST，对于早一些的版本，2.2这种可能还会使用 OBJ_ENCODING_ZIPLIST，OBJ_ENCODING_LINKEDLIST
当 type 是 OBJ_SET 时，是个集合，但是得看具体元素的类型，有可能使用整数集合，OBJ_ENCODING_INTSET, 如果元素不全是整型或者数量超过一定限制，那么编码就是 OBJ_ENCODING_HT hash table 了
当 type 是 OBJ_ZSET 时，是个有序集合，它底层有可能使用的是 OBJ_ENCODING_ZIPLIST 或者 OBJ_ENCODING_SKIPLIST
当 type 是 OBJ_HASH 时，一开始也是 OBJ_ENCODING_ZIPLIST，然后当数据量大于 hash_max_ziplist_entries 时会转成 OBJ_ENCODING_HT
-
]]>
Redis
@@ -5507,47 +5445,53 @@ REDIS_STATIC void __quicklistInsertNode(quicklist *quicklist,
- 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/
- 在 redis 中还有一类表型数据结构叫压缩表，ziplist，它的目的是替代链表，链表是个很容易理解的数据结构，双向链表有前后指针，有带头结点的有的不带，但是链表有个比较大的问题是相对于普通的数组，它的内存不连续，碎片化的存储，内存利用效率不高，而且指针寻址相对于直接使用偏移量的话，也有一定的效率劣势，当然这不是主要的原因，ziplist 设计的主要目的是让链表的内存使用更高效
-
-The ziplist is a specially encoded dually linked list that is designed to be very memory efficient.
这是摘自 redis 源码中ziplist.c 文件的注释，也说明了原因，它的大概结构是这样子
-
-<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>
-其中
<zlbytes>表示 ziplist 占用的字节总数，类型是uint32_t，32 位的无符号整型，当然表示的字节数也包含自己本身占用的 4 个
<zltail> 类型也是是uint32_t，表示ziplist表中最后一项（entry）在ziplist中的偏移字节数。<zltail>的存在，使得我们可以很方便地找到最后一项（不用遍历整个ziplist），从而可以在ziplist尾端快速地执行push或pop操作。
<uint16_t zllen> 表示ziplist 中的数据项个数，因为是 16 位，所以当数量超过所能表示的最大的数量，它的 16 位全会置为 1，但是真实的数量需要遍历整个 ziplist 才能知道
<entry>是具体的数据项，后面解释
<zlend> ziplist 的最后一个字节，固定是255。
再看一下<entry>中的具体结构，
-<prevlen> <encoding> <entry-data>
-首先这个<prevlen>有两种情况，一种是前面的元素的长度，如果是小于等于 253的时候就用一个uint8_t 来表示前一元素的长度，如果大于的话他将占用五个字节，第一个字节是 254，即表示这个字节已经表示不下了，需要后面的四个字节帮忙表示
<encoding>这个就比较复杂，把源码的注释放下面先看下
-* |00pppppp| - 1 byte
-* String value with length less than or equal to 63 bytes (6 bits).
-* "pppppp" represents the unsigned 6 bit length.
-* |01pppppp|qqqqqqqq| - 2 bytes
-* String value with length less than or equal to 16383 bytes (14 bits).
-* IMPORTANT: The 14 bit number is stored in big endian.
-* |10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| - 5 bytes
-* String value with length greater than or equal to 16384 bytes.
-* Only the 4 bytes following the first byte represents the length
-* up to 32^2-1. The 6 lower bits of the first byte are not used and
-* are set to zero.
-* IMPORTANT: The 32 bit number is stored in big endian.
-* |11000000| - 3 bytes
-* Integer encoded as int16_t (2 bytes).
-* |11010000| - 5 bytes
-* Integer encoded as int32_t (4 bytes).
-* |11100000| - 9 bytes
-* Integer encoded as int64_t (8 bytes).
-* |11110000| - 4 bytes
-* Integer encoded as 24 bit signed (3 bytes).
-* |11111110| - 2 bytes
-* Integer encoded as 8 bit signed (1 byte).
-* |1111xxxx| - (with xxxx between 0000 and 1101) immediate 4 bit integer.
-* Unsigned integer from 0 to 12. The encoded value is actually from
-* 1 to 13 because 0000 and 1111 can not be used, so 1 should be
-* subtracted from the encoded 4 bit value to obtain the right value.
-* |11111111| - End of ziplist special entry.
-首先如果 encoding 的前两位是 00 的话代表这个元素是个 6 位的字符串，即直接将数据保存在 encoding 中，不消耗额外的<entry-data>，如果前两位是 01 的话表示是个 14 位的字符串，如果是 10 的话表示encoding 块之后的四个字节是存放字符串类型的数据，encoding 的剩余 6 位置 0。
如果 encoding 的前两位是 11 的话表示这是个整型，具体的如果后两位是00的话，表示后面是个2字节的 int16_t 类型，如果是01的话，后面是个4字节的int32_t,如果是10的话后面是8字节的int64_t,如果是 11 的话后面是 3 字节的有符号整型，这些都要最后 4 位都是 0 的情况噢
剩下当是11111110时，则表示是一个1 字节的有符号数，如果是 1111xxxx，其中xxxx在0000 到 1101 表示实际的 1 到 13，为啥呢，因为 0000 前面已经用过了，而 1110 跟 1111 也都有用了。
看个具体的例子(上下有点对不齐，将就看)
-[0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff]
-|**zlbytes***| |***zltail***| |*zllen*| |entry1 entry2| |zlend|
-第一部分代表整个 ziplist 有 15 个字节，zlbytes 自己占了 4 个 zltail 表示最后一个元素的偏移量，第 13 个字节起，zllen 表示有 2 个元素，第一个元素是00f3,00表示前一个元素长度是 0，本来前面就没元素(不过不知道这个能不能优化这一字节)，然后是 f3，换成二进制就是11110011,对照上面的注释，是落在|1111xxxx|这个类型里，注意这个其实是用 0001 到 1101 也就是 1到 13 来表示 0到 12，所以 f3 应该就是 2，第一个元素是 2，第二个元素呢，02 代表前一个元素也就是刚才说的这个，占用 2 字节，f6 展开也是刚才的类型，实际是 5，ff 表示 ziplist 的结尾，所以这个 ziplist 里面是两个元素，2 跟 5
+ redis数据结构介绍五-第五部分 对象
+ /2020/01/20/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%BA%94/
+ 前面说了这么些数据结构，其实大家对于 redis 最初的印象应该就是个 key-value 的缓存，类似于 memcache，redis 其实也是个 key-value，key 还是一样的字符串，或者说就是用 redis 自己的动态字符串实现，但是 value 其实就是前面说的那些数据结构，差不多快说完了，还有个 quicklist 后面还有一篇，这里先介绍下 redis 对于这些不同类型的 value 是怎么实现的，首先看下 redisObject 的源码头文件
+/* The actual Redis Object */
+#define OBJ_STRING 0 /* String object. */
+#define OBJ_LIST 1 /* List object. */
+#define OBJ_SET 2 /* Set object. */
+#define OBJ_ZSET 3 /* Sorted set object. */
+#define OBJ_HASH 4 /* Hash object. */
+/*
+ * Objects encoding. Some kind of objects like Strings and Hashes can be
+ * internally represented in multiple ways. The 'encoding' field of the object
+ * is set to one of this fields for this object. */
+#define OBJ_ENCODING_RAW 0 /* Raw representation */
+#define OBJ_ENCODING_INT 1 /* Encoded as integer */
+#define OBJ_ENCODING_HT 2 /* Encoded as hash table */
+#define OBJ_ENCODING_ZIPMAP 3 /* Encoded as zipmap */
+#define OBJ_ENCODING_LINKEDLIST 4 /* No longer used: old list encoding. */
+#define OBJ_ENCODING_ZIPLIST 5 /* Encoded as ziplist */
+#define OBJ_ENCODING_INTSET 6 /* Encoded as intset */
+#define OBJ_ENCODING_SKIPLIST 7 /* Encoded as skiplist */
+#define OBJ_ENCODING_EMBSTR 8 /* Embedded sds string encoding */
+#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list of ziplists */
+#define OBJ_ENCODING_STREAM 10 /* Encoded as a radix tree of listpacks */
+
+#define LRU_BITS 24
+#define LRU_CLOCK_MAX ((1<<LRU_BITS)-1) /* Max value of obj->lru */
+#define LRU_CLOCK_RESOLUTION 1000 /* LRU clock resolution in ms */
+
+#define OBJ_SHARED_REFCOUNT INT_MAX
+typedef struct redisObject {
+ unsigned type:4;
+ unsigned encoding:4;
+ unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
+ * LFU data (least significant 8 bits frequency
+ * and most significant 16 bits access time). */
+ int refcount;
+ void *ptr;
+} robj;
+主体结构就是这个 redisObject，
+
+- type： 字段表示对象的类型，它对应的就是 redis 的对外暴露的，或者说用户可以使用的五种类型，OBJ_STRING, OBJ_LIST, OBJ_SET, OBJ_ZSET, OBJ_HASH
+- encoding： 字段表示这个对象在 redis 内部的编码方式，由OBJ_ENCODING_开头的 11 种
+- lru: 做LRU替换算法用，占24个bit
+- refcount: 引用计数。它允许robj对象在某些情况下被共享。
+- ptr: 指向底层实现数据结构的指针
当 type 是 OBJ_STRING 时，表示类型是个 string，它的编码方式 encoding 可能有 OBJ_ENCODING_RAW，OBJ_ENCODING_INT，OBJ_ENCODING_EMBSTR 三种
当 type 是 OBJ_LIST 时，表示类型是 list，它的编码方式 encoding 是 OBJ_ENCODING_QUICKLIST，对于早一些的版本，2.2这种可能还会使用 OBJ_ENCODING_ZIPLIST，OBJ_ENCODING_LINKEDLIST
当 type 是 OBJ_SET 时，是个集合，但是得看具体元素的类型，有可能使用整数集合，OBJ_ENCODING_INTSET, 如果元素不全是整型或者数量超过一定限制，那么编码就是 OBJ_ENCODING_HT hash table 了
当 type 是 OBJ_ZSET 时，是个有序集合，它底层有可能使用的是 OBJ_ENCODING_ZIPLIST 或者 OBJ_ENCODING_SKIPLIST
当 type 是 OBJ_HASH 时，一开始也是 OBJ_ENCODING_ZIPLIST，然后当数据量大于 hash_max_ziplist_entries 时会转成 OBJ_ENCODING_HT
+
]]>
Redis
@@ -7113,6 +7057,31 @@ user3:
jvm
+
+ 介绍下最近比较实用的端口转发
+ /2021/11/14/%E4%BB%8B%E7%BB%8D%E4%B8%8B%E6%9C%80%E8%BF%91%E6%AF%94%E8%BE%83%E5%AE%9E%E7%94%A8%E7%9A%84%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91/
+ vscode 扩展转发在日常使用云服务器的时候，如果要访问上面自建的 mysql，一般要不直接开对应的端口，然后需要对本地 ip 进行授权，但是这个方案会有比较多的限制，比如本地 ip 变了，比如是非固定出口 ip 的家用宽带，或者要在家里跟公司都要访问，如果对所有 ip 都授权的话会不安全，这个时候其实是用 ssh 端口转发是个比较安全方便的方式。
原来在这个之前其实对这块内容不太了解，后面是听朋友说的，vscode 的 Remote - SSH 扩展可以很方便的使用端口转发，在使用该扩展的时候，会在控制台位置里都出现一个”端口” tab
![]()
如图中所示，我就是将一个服务器上的 mysql 的 3306 端口转发到本地的 3307 端口，至于为什么不用 3306 是因为本地我也有个 mysql 已经使用了 3306 端口，这个方法是使用的 vscode 的这个扩展，
+ssh 命令转发
还有个方式是直接使用 ssh 命令
命令可以如此
+ssh -CfNg -L 3307:127.0.0.1:3306 user1@199.199.199.199
+简单介绍下这个命令
-C 表示的是压缩数据包
-f 表示后台执行命令
-N 是表示不执行具体命令只用于端口转发
-g 表示允许远程主机连接本地转发端口
-L 则是具体端口转发的映射配置
上面的命令就是将远程主机的 127.0.0.1:3306 对应转发到本地 3307
而后面的用户则就是登录主机的用户名user1和ip地址199.199.199.199，当然这个配置也不是唯一的
+ssh config 配置转发
还可以在ssh 的 config 配置中加对应的配置
+Host host1
+ HostName 199.199.199.199
+ User user1
+ IdentityFile /Users/user1/.ssh/id_rsa
+ ServerAliveInterval 60
+ LocalForward 3310 127.0.0.1:3306
+然后通过 ssh host1 连接服务器的时候就能顺带做端口转发
+]]>
+
+ ssh
+ 技巧
+
+
+ ssh
+ 端口转发
+
+
介绍一下 RocketMQ
/2020/06/21/%E4%BB%8B%E7%BB%8D%E4%B8%80%E4%B8%8B-RocketMQ/
@@ -7182,31 +7151,6 @@ user3:
中间件
-
- 介绍下最近比较实用的端口转发
- /2021/11/14/%E4%BB%8B%E7%BB%8D%E4%B8%8B%E6%9C%80%E8%BF%91%E6%AF%94%E8%BE%83%E5%AE%9E%E7%94%A8%E7%9A%84%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91/
- vscode 扩展转发在日常使用云服务器的时候，如果要访问上面自建的 mysql，一般要不直接开对应的端口，然后需要对本地 ip 进行授权，但是这个方案会有比较多的限制，比如本地 ip 变了，比如是非固定出口 ip 的家用宽带，或者要在家里跟公司都要访问，如果对所有 ip 都授权的话会不安全，这个时候其实是用 ssh 端口转发是个比较安全方便的方式。
原来在这个之前其实对这块内容不太了解，后面是听朋友说的，vscode 的 Remote - SSH 扩展可以很方便的使用端口转发，在使用该扩展的时候，会在控制台位置里都出现一个”端口” tab
![]()
如图中所示，我就是将一个服务器上的 mysql 的 3306 端口转发到本地的 3307 端口，至于为什么不用 3306 是因为本地我也有个 mysql 已经使用了 3306 端口，这个方法是使用的 vscode 的这个扩展，
-ssh 命令转发
还有个方式是直接使用 ssh 命令
命令可以如此
-ssh -CfNg -L 3307:127.0.0.1:3306 user1@199.199.199.199
-简单介绍下这个命令
-C 表示的是压缩数据包
-f 表示后台执行命令
-N 是表示不执行具体命令只用于端口转发
-g 表示允许远程主机连接本地转发端口
-L 则是具体端口转发的映射配置
上面的命令就是将远程主机的 127.0.0.1:3306 对应转发到本地 3307
而后面的用户则就是登录主机的用户名user1和ip地址199.199.199.199，当然这个配置也不是唯一的
-ssh config 配置转发
还可以在ssh 的 config 配置中加对应的配置
-Host host1
- HostName 199.199.199.199
- User user1
- IdentityFile /Users/user1/.ssh/id_rsa
- ServerAliveInterval 60
- LocalForward 3310 127.0.0.1:3306
-然后通过 ssh host1 连接服务器的时候就能顺带做端口转发
-]]>
-
- ssh
- 技巧
-
-
- ssh
- 端口转发
-
-
从丁仲礼被美国制裁聊点啥
/2020/12/20/%E4%BB%8E%E4%B8%81%E4%BB%B2%E7%A4%BC%E8%A2%AB%E7%BE%8E%E5%9B%BD%E5%88%B6%E8%A3%81%E8%81%8A%E7%82%B9%E5%95%A5/
@@ -7269,95 +7213,6 @@ user3:
健康码
-
- 关于读书打卡与分享
- /2021/02/07/%E5%85%B3%E4%BA%8E%E8%AF%BB%E4%B9%A6%E6%89%93%E5%8D%A1%E4%B8%8E%E5%88%86%E4%BA%AB/
- 最近群里大佬发起了一个读书打卡活动，需要每天读一会书，在群里打卡分享感悟，争取一个月能读完一本书，说实话一天十分钟的读书时间倒是问题不大，不过每天都要打卡，而且一个月要读完一本书，其实难度还是有点大的，不过也想试试看。
之前某某老大给自己立了个 flag，说要读一百本书，这对我来说挺难实现的，一则我也不喜欢书只读一小半，二则感觉对于喜欢看的内容范围还是比较有限制，可能也算是比较矫情，不爱追热门的各类东西，因为往往会有一些跟大众不一致的观点看法，显得格格不入。所以还是这个打卡活动可能会比较适合我，书是人类进步的阶梯。
到现在是打卡了三天了，读的主要是白岩松的《幸福了吗》，对于白岩松，我们这一代人是比较熟悉，并且整体印象比较不错的一个央视主持人，从《焦点访谈》开始，到疫情期间的各类一线节目，可能对我来说是个三观比较正，敢于说一些真话的主持人，这中间其实是有个空档期，没怎么看电视，也不太关注了，只是在疫情期间的节目，还是一如既往地给人一种可靠的感觉，正好有一次偶然微信读书推荐了白岩松的这本书，就看了一部分，正好这次继续往下看，因为相对来讲不会很晦涩，并且从这位知名央视主持人的角度分享他的过往和想法看法，还是比较有意思的。
从对汶川地震，08 年奥运等往事的回忆和一些细节的呈现，也让我了解比较多当时所不知道的，特别是汶川地震，那时的我还在读高中，真的是看着电视，作为“猛男”都忍不住泪目了，共和国之殇，多难兴邦，但是这对于当事人来说，都是一场醒不过来的噩梦。
然后是对于足球的热爱，其实光这个就能掰扯很多，因为我不爱足球，只爱篮球，其中原因有的没的也挺多可以说的，但是看了他的书，才能比较深入的了解一个足球迷，对足球，对中国足球，对世界杯，对阿根廷的感情。
接下去还是想能继续坚持下去，加油！
-]]>
-
- 生活
- 读后感
- 白岩松
- 幸福了吗
-
-
- 读后感
- 读书
- 打卡
- 幸福了吗
- 足球
-
-
-
- 上次的其他 外行聊国足
- /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 年前应该有了质的变化，身体素质也越来越好，即使是体育弱国，这么继续走下坡路，半死不活的，不觉得是打了自己的脸么。足球也需要基本功，基本的体能，力量这些，看看现在这些国足运动员的体型，对比下女足，说实话，如果男足这些运动员都练得不错的体脂率，耐力等，成绩即使不好，也不会比现在更差。
纯主观吐槽，勿喷。
-]]>
-
- 生活
- 运动
-
-
- 生活
-
-
-
- 周末我在老丈人家打了天小工
- /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%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。
-]]>
-
- 生活
- 运动
- 跑步
- 干活
-
-
- 生活
- 运动
- 减肥
- 跑步
- 干活
-
-
-
- 分享记录一下一个 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
-
-
-
- 分享记录一下一个 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"
-
-
-]]>
-
- git
- 小技巧
-
-
- git
-
-
在老丈人家的小工记三
/2020/09/13/%E5%9C%A8%E8%80%81%E4%B8%88%E4%BA%BA%E5%AE%B6%E7%9A%84%E5%B0%8F%E5%B7%A5%E8%AE%B0%E4%B8%89/
@@ -7418,6 +7273,19 @@ 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%左右，剩下的我的手已经不会用力了，因为那一块应该是要糊上去的始作俑者，就一块里面凹进去的，我拿着榔头敲到我手已经没法使劲了，而且大下午，感觉没五分钟，我的汗已经糊满脸，眼睛也睁不开，不然就流到眼睛里了，此处获得成就一：用榔头敲墙壁，也是个技术加体力的活，而且需要非常好的技巧，否则手马上就废了，敲下去的反作用力，没一会就不行了，然后是看着老丈人兄弟帮忙拆一个柜子，在我看来是个几天都搞不定的活，他轻轻松松在我敲墙的那会就搞定了，以前总觉得我干的活非常有技术含量，可是这个事情真的也是很有技巧啊，它是个把一间房间分隔开的柜子，从底到顶上，还带着门，我还在旁边帮忙撬一下脚踢，一根木条撬半天，唉，成就二：专业的人就是不一样。
最后就是成就三了：我之前沾沾自喜的跑了多少步，做了什么锻炼，其实都是渣渣，像这样干一天活，没经历过的，基本大半天就废了，反过来说，如果能经常去这么干一天活，跑步啥的都是渣渣，消耗的能量远远超过跑个十公里啥的。
+]]>
+
+ 生活
+ 运动
+ 跑步
+ 干活
+
+
+ 生活
+ 运动
+ 减肥
+ 跑步
+ 干活
+
+
+
+ 分享记录一下一个 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
+
+
+
+ 分享记录一下一个 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"
+
+
+]]>
+
+ git
+ 小技巧
+
+
+ git
+
+
看完了扫黑风暴,聊聊感想
/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/
@@ -8911,87 +8836,30 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"这篇文章，个人感觉写得非常好，在 rocketmq 中，最大的一块存储就是消息存储，也就是 CommitLog ，当然还有 ConsumeQueue 和 IndexFile，以及其他一些文件，CommitLog 的存储是以一个 1G 大小的文件作为存储单位，写完了就再建一个，那么如何提高这 1G 文件的读写效率呢，就是 mmap，传统意义的读写文件，read，write 都需要由系统调用，来回地在用户态跟内核态进行拷贝切换，
-read(file, tmp_buf, len);
-write(socket, tmp_buf, len);
+ 聊一下 RocketMQ 的消息存储三
+ /2021/10/03/%E8%81%8A%E4%B8%80%E4%B8%8B-RocketMQ-%E7%9A%84%E6%B6%88%E6%81%AF%E5%AD%98%E5%82%A8%E4%B8%89/
+ ConsumeQueue 其实是定位到一个 topic 下的消息在 CommitLog 下的偏移量，它也是固定大小的
+// ConsumeQueue file size,default is 30W
+private int mapedFileSizeConsumeQueue = 300000 * ConsumeQueue.CQ_STORE_UNIT_SIZE;
+public static final int CQ_STORE_UNIT_SIZE = 20;
+所以文件大小是5.7M 左右
+![5udpag]()
+ConsumeQueue 的构建是通过org.apache.rocketmq.store.DefaultMessageStore.ReputMessageService运行后的 doReput 方法，而启动是的 reputFromOffset 则是通过org.apache.rocketmq.store.DefaultMessageStore#start中下面代码设置并启动
+log.info("[SetReputOffset] maxPhysicalPosInLogicQueue={} clMinOffset={} clMaxOffset={} clConfirmedOffset={}",
+ maxPhysicalPosInLogicQueue, this.commitLog.getMinOffset(), this.commitLog.getMaxOffset(), this.commitLog.getConfirmOffset());
+ this.reputMessageService.setReputFromOffset(maxPhysicalPosInLogicQueue);
+ this.reputMessageService.start();
-![vms95Z]()
-如上面的图显示的，要在用户态跟内核态进行切换，数据还需要在内核缓冲跟用户缓冲之间拷贝多次，
-
-
-- 第一步是调用 read，需要在用户态切换成内核态，DMA模块从磁盘中读取文件，并存储在内核缓冲区，相当于是第一次复制
-- 数据从内核缓冲区被拷贝到用户缓冲区，read 调用返回，伴随着内核态又切换成用户态，完成了第二次复制
-- 然后是write 写入，这里也会伴随着用户态跟内核态的切换，数据从用户缓冲区被复制到内核空间缓冲区，完成了第三次复制，这次有点不一样的是数据不是在内核缓冲区了，会复制到 socket buffer 中。
-- write 系统调用返回，又切换回了用户态，然后数据由 DMA 拷贝到协议引擎。
-
-
-如此就能看出其实默认的读写操作代价是非常大的，而在 rocketmq 等高性能中间件中都有使用的零拷贝技术，其中 rocketmq 使用的是 mmap
-mmap
mmap基于 OS 的 mmap 的内存映射技术，通过MMU 映射文件，将文件直接映射到用户态的内存地址，使得对文件的操作不再是 write/read,而转化为直接对内存地址的操作，使随机读写文件和读写内存相似的速度。
-
-mmap 把文件映射到用户空间里的虚拟内存，省去了从内核缓冲区复制到用户空间的过程，文件中的位置在虚拟内存中有了对应的地址，可以像操作内存一样操作这个文件，这样的文件读写文件方式少了数据从内核缓存到用户空间的拷贝，效率很高。
-
-tmp_buf = mmap(file, len);
-write(socket, tmp_buf, len);
-
-![I68mFx]()
-
-第一步：mmap系统调用使得文件内容被DMA引擎复制到内核缓冲区。然后该缓冲区与用户进程共享，在内核和用户内存空间之间不进行任何拷贝。
-第二步：写系统调用使得内核将数据从原来的内核缓冲区复制到与套接字相关的内核缓冲区。
-第三步：第三次拷贝发生在DMA引擎将数据从内核套接字缓冲区传递给协议引擎时。
-通过使用mmap而不是read，我们将内核需要拷贝的数据量减少了一半。当大量的数据被传输时，这将有很好的效果。然而，这种改进并不是没有代价的；在使用mmap+write方法时，有一些隐藏的陷阱。例如当你对一个文件进行内存映射，然后在另一个进程截断同一文件时调用写。你的写系统调用将被总线错误信号SIGBUS打断，因为你执行了一个错误的内存访问。该信号的默认行为是杀死进程并dumpcore–这对网络服务器来说不是最理想的操作。
-有两种方法可以解决这个问题。
-第一种方法是为SIGBUS信号安装一个信号处理程序，然后在处理程序中简单地调用返回。通过这样做，写系统调用会返回它在被打断之前所写的字节数，并将errno设置为成功。让我指出，这将是一个糟糕的解决方案，一个治标不治本的解决方案。因为SIGBUS预示着进程出了严重的问题，所以不鼓励使用这种解决方案。
-第二个解决方案涉及内核的文件租赁（在Windows中称为 “机会锁”）。这是解决这个问题的正确方法。通过在文件描述符上使用租赁，你与内核在一个特定的文件上达成租约。然后你可以向内核请求一个读/写租约。当另一个进程试图截断你正在传输的文件时，内核会向你发送一个实时信号，即RT_SIGNAL_LEASE信号。它告诉你内核即将终止你对该文件的写或读租约。在你的程序访问一个无效的地址和被SIGBUS信号杀死之前，你的写调用会被打断了。写入调用的返回值是中断前写入的字节数，errno将被设置为成功。下面是一些示例代码，显示了如何从内核中获得租约。
-if(fcntl(fd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
- perror("kernel lease set signal");
- return -1;
-}
-/* l_type can be F_RDLCK F_WRLCK */
-if(fcntl(fd, F_SETLEASE, l_type)){
- perror("kernel lease set type");
- return -1;
-}
-]]>
-
- MQ
- RocketMQ
- 消息队列
-
-
- MQ
- 消息队列
- RocketMQ
-
-
-
- 聊一下 RocketMQ 的消息存储三
- /2021/10/03/%E8%81%8A%E4%B8%80%E4%B8%8B-RocketMQ-%E7%9A%84%E6%B6%88%E6%81%AF%E5%AD%98%E5%82%A8%E4%B8%89/
- ConsumeQueue 其实是定位到一个 topic 下的消息在 CommitLog 下的偏移量，它也是固定大小的
-// ConsumeQueue file size,default is 30W
-private int mapedFileSizeConsumeQueue = 300000 * ConsumeQueue.CQ_STORE_UNIT_SIZE;
-
-public static final int CQ_STORE_UNIT_SIZE = 20;
-
-所以文件大小是5.7M 左右
-![5udpag]()
-ConsumeQueue 的构建是通过org.apache.rocketmq.store.DefaultMessageStore.ReputMessageService运行后的 doReput 方法，而启动是的 reputFromOffset 则是通过org.apache.rocketmq.store.DefaultMessageStore#start中下面代码设置并启动
-log.info("[SetReputOffset] maxPhysicalPosInLogicQueue={} clMinOffset={} clMaxOffset={} clConfirmedOffset={}",
- maxPhysicalPosInLogicQueue, this.commitLog.getMinOffset(), this.commitLog.getMaxOffset(), this.commitLog.getConfirmOffset());
- this.reputMessageService.setReputFromOffset(maxPhysicalPosInLogicQueue);
- this.reputMessageService.start();
-
-看一下 doReput 的逻辑
-private void doReput() {
- if (this.reputFromOffset < DefaultMessageStore.this.commitLog.getMinOffset()) {
- log.warn("The reputFromOffset={} is smaller than minPyOffset={}, this usually indicate that the dispatch behind too much and the commitlog has expired.",
- this.reputFromOffset, DefaultMessageStore.this.commitLog.getMinOffset());
- this.reputFromOffset = DefaultMessageStore.this.commitLog.getMinOffset();
- }
- for (boolean doNext = true; this.isCommitLogAvailable() && doNext; ) {
+看一下 doReput 的逻辑
+private void doReput() {
+ if (this.reputFromOffset < DefaultMessageStore.this.commitLog.getMinOffset()) {
+ log.warn("The reputFromOffset={} is smaller than minPyOffset={}, this usually indicate that the dispatch behind too much and the commitlog has expired.",
+ this.reputFromOffset, DefaultMessageStore.this.commitLog.getMinOffset());
+ this.reputFromOffset = DefaultMessageStore.this.commitLog.getMinOffset();
+ }
+ for (boolean doNext = true; this.isCommitLogAvailable() && doNext; ) {
if (DefaultMessageStore.this.getMessageStoreConfig().isDuplicationEnable()
&& this.reputFromOffset >= DefaultMessageStore.this.getConfirmOffset()) {
@@ -9103,6 +8971,151 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"
偏移量，消息大小，跟 tag 的 hashCode
+]]>
+
+ MQ
+ RocketMQ
+ 消息队列
+
+
+ MQ
+ 消息队列
+ RocketMQ
+
+
+
+ 搬运两个 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”。另请参阅
+
+]]>
+
+ Mysql
+
+
+ mysql
+ 字符集
+ 编码
+ utf8
+ utf8mb4
+ utf8mb4_0900_ai_ci
+ utf8mb4_unicode_ci
+ utf8mb4_general_ci
+
+
+
+ 聊一下 RocketMQ 的消息存储之 MMAP
+ /2021/09/04/%E8%81%8A%E4%B8%80%E4%B8%8B-RocketMQ-%E7%9A%84%E6%B6%88%E6%81%AF%E5%AD%98%E5%82%A8/
+ 这是个很大的话题了，可能会分成两部分说，第一部分就是所谓的零拷贝 ( zero-copy )，这一块其实也不新鲜，我对零拷贝的概念主要来自这篇文章，个人感觉写得非常好，在 rocketmq 中，最大的一块存储就是消息存储，也就是 CommitLog ，当然还有 ConsumeQueue 和 IndexFile，以及其他一些文件，CommitLog 的存储是以一个 1G 大小的文件作为存储单位，写完了就再建一个，那么如何提高这 1G 文件的读写效率呢，就是 mmap，传统意义的读写文件，read，write 都需要由系统调用，来回地在用户态跟内核态进行拷贝切换，
+read(file, tmp_buf, len);
+write(socket, tmp_buf, len);
+
+
+
+![vms95Z]()
+如上面的图显示的，要在用户态跟内核态进行切换，数据还需要在内核缓冲跟用户缓冲之间拷贝多次，
+
+
+- 第一步是调用 read，需要在用户态切换成内核态，DMA模块从磁盘中读取文件，并存储在内核缓冲区，相当于是第一次复制
+- 数据从内核缓冲区被拷贝到用户缓冲区，read 调用返回，伴随着内核态又切换成用户态，完成了第二次复制
+- 然后是write 写入，这里也会伴随着用户态跟内核态的切换，数据从用户缓冲区被复制到内核空间缓冲区，完成了第三次复制，这次有点不一样的是数据不是在内核缓冲区了，会复制到 socket buffer 中。
+- write 系统调用返回，又切换回了用户态，然后数据由 DMA 拷贝到协议引擎。
+
+
+如此就能看出其实默认的读写操作代价是非常大的，而在 rocketmq 等高性能中间件中都有使用的零拷贝技术，其中 rocketmq 使用的是 mmap
+mmap
mmap基于 OS 的 mmap 的内存映射技术，通过MMU 映射文件，将文件直接映射到用户态的内存地址，使得对文件的操作不再是 write/read,而转化为直接对内存地址的操作，使随机读写文件和读写内存相似的速度。
+
+mmap 把文件映射到用户空间里的虚拟内存，省去了从内核缓冲区复制到用户空间的过程，文件中的位置在虚拟内存中有了对应的地址，可以像操作内存一样操作这个文件，这样的文件读写文件方式少了数据从内核缓存到用户空间的拷贝，效率很高。
+
+tmp_buf = mmap(file, len);
+write(socket, tmp_buf, len);
+
+![I68mFx]()
+
+第一步：mmap系统调用使得文件内容被DMA引擎复制到内核缓冲区。然后该缓冲区与用户进程共享，在内核和用户内存空间之间不进行任何拷贝。
+第二步：写系统调用使得内核将数据从原来的内核缓冲区复制到与套接字相关的内核缓冲区。
+第三步：第三次拷贝发生在DMA引擎将数据从内核套接字缓冲区传递给协议引擎时。
+通过使用mmap而不是read，我们将内核需要拷贝的数据量减少了一半。当大量的数据被传输时，这将有很好的效果。然而，这种改进并不是没有代价的；在使用mmap+write方法时，有一些隐藏的陷阱。例如当你对一个文件进行内存映射，然后在另一个进程截断同一文件时调用写。你的写系统调用将被总线错误信号SIGBUS打断，因为你执行了一个错误的内存访问。该信号的默认行为是杀死进程并dumpcore–这对网络服务器来说不是最理想的操作。
+有两种方法可以解决这个问题。
+第一种方法是为SIGBUS信号安装一个信号处理程序，然后在处理程序中简单地调用返回。通过这样做，写系统调用会返回它在被打断之前所写的字节数，并将errno设置为成功。让我指出，这将是一个糟糕的解决方案，一个治标不治本的解决方案。因为SIGBUS预示着进程出了严重的问题，所以不鼓励使用这种解决方案。
+第二个解决方案涉及内核的文件租赁（在Windows中称为 “机会锁”）。这是解决这个问题的正确方法。通过在文件描述符上使用租赁，你与内核在一个特定的文件上达成租约。然后你可以向内核请求一个读/写租约。当另一个进程试图截断你正在传输的文件时，内核会向你发送一个实时信号，即RT_SIGNAL_LEASE信号。它告诉你内核即将终止你对该文件的写或读租约。在你的程序访问一个无效的地址和被SIGBUS信号杀死之前，你的写调用会被打断了。写入调用的返回值是中断前写入的字节数，errno将被设置为成功。下面是一些示例代码，显示了如何从内核中获得租约。
+if(fcntl(fd, F_SETSIG, RT_SIGNAL_LEASE) == -1) {
+ perror("kernel lease set signal");
+ return -1;
+}
+/* l_type can be F_RDLCK F_WRLCK */
+if(fcntl(fd, F_SETLEASE, l_type)){
+ perror("kernel lease set type");
+ return -1;
+}
]]>
MQ
@@ -10078,6 +10091,62 @@ git commit -m "revert OLDER_COMMIT to NEWER_COMMIT"<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>
+其中
<zlbytes>表示 ziplist 占用的字节总数，类型是uint32_t，32 位的无符号整型，当然表示的字节数也包含自己本身占用的 4 个
<zltail> 类型也是是uint32_t，表示ziplist表中最后一项（entry）在ziplist中的偏移字节数。<zltail>的存在，使得我们可以很方便地找到最后一项（不用遍历整个ziplist），从而可以在ziplist尾端快速地执行push或pop操作。
<uint16_t zllen> 表示ziplist 中的数据项个数，因为是 16 位，所以当数量超过所能表示的最大的数量，它的 16 位全会置为 1，但是真实的数量需要遍历整个 ziplist 才能知道
<entry>是具体的数据项，后面解释
<zlend> ziplist 的最后一个字节，固定是255。
再看一下<entry>中的具体结构，
+<prevlen> <encoding> <entry-data>
+首先这个<prevlen>有两种情况，一种是前面的元素的长度，如果是小于等于 253的时候就用一个uint8_t 来表示前一元素的长度，如果大于的话他将占用五个字节，第一个字节是 254，即表示这个字节已经表示不下了，需要后面的四个字节帮忙表示
<encoding>这个就比较复杂，把源码的注释放下面先看下
+* |00pppppp| - 1 byte
+* String value with length less than or equal to 63 bytes (6 bits).
+* "pppppp" represents the unsigned 6 bit length.
+* |01pppppp|qqqqqqqq| - 2 bytes
+* String value with length less than or equal to 16383 bytes (14 bits).
+* IMPORTANT: The 14 bit number is stored in big endian.
+* |10000000|qqqqqqqq|rrrrrrrr|ssssssss|tttttttt| - 5 bytes
+* String value with length greater than or equal to 16384 bytes.
+* Only the 4 bytes following the first byte represents the length
+* up to 32^2-1. The 6 lower bits of the first byte are not used and
+* are set to zero.
+* IMPORTANT: The 32 bit number is stored in big endian.
+* |11000000| - 3 bytes
+* Integer encoded as int16_t (2 bytes).
+* |11010000| - 5 bytes
+* Integer encoded as int32_t (4 bytes).
+* |11100000| - 9 bytes
+* Integer encoded as int64_t (8 bytes).
+* |11110000| - 4 bytes
+* Integer encoded as 24 bit signed (3 bytes).
+* |11111110| - 2 bytes
+* Integer encoded as 8 bit signed (1 byte).
+* |1111xxxx| - (with xxxx between 0000 and 1101) immediate 4 bit integer.
+* Unsigned integer from 0 to 12. The encoded value is actually from
+* 1 to 13 because 0000 and 1111 can not be used, so 1 should be
+* subtracted from the encoded 4 bit value to obtain the right value.
+* |11111111| - End of ziplist special entry.
+首先如果 encoding 的前两位是 00 的话代表这个元素是个 6 位的字符串，即直接将数据保存在 encoding 中，不消耗额外的<entry-data>，如果前两位是 01 的话表示是个 14 位的字符串，如果是 10 的话表示encoding 块之后的四个字节是存放字符串类型的数据，encoding 的剩余 6 位置 0。
如果 encoding 的前两位是 11 的话表示这是个整型，具体的如果后两位是00的话，表示后面是个2字节的 int16_t 类型，如果是01的话，后面是个4字节的int32_t,如果是10的话后面是8字节的int64_t,如果是 11 的话后面是 3 字节的有符号整型，这些都要最后 4 位都是 0 的情况噢
剩下当是11111110时，则表示是一个1 字节的有符号数，如果是 1111xxxx，其中xxxx在0000 到 1101 表示实际的 1 到 13，为啥呢，因为 0000 前面已经用过了，而 1110 跟 1111 也都有用了。
看个具体的例子(上下有点对不齐，将就看)
+[0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff]
+|**zlbytes***| |***zltail***| |*zllen*| |entry1 entry2| |zlend|
+第一部分代表整个 ziplist 有 15 个字节，zlbytes 自己占了 4 个 zltail 表示最后一个元素的偏移量，第 13 个字节起，zllen 表示有 2 个元素，第一个元素是00f3,00表示前一个元素长度是 0，本来前面就没元素(不过不知道这个能不能优化这一字节)，然后是 f3，换成二进制就是11110011,对照上面的注释，是落在|1111xxxx|这个类型里，注意这个其实是用 0001 到 1101 也就是 1到 13 来表示 0到 12，所以 f3 应该就是 2，第一个元素是 2，第二个元素呢，02 代表前一个元素也就是刚才说的这个，占用 2 字节，f6 展开也是刚才的类型，实际是 5，ff 表示 ziplist 的结尾，所以这个 ziplist 里面是两个元素，2 跟 5
+]]>
+
+ Redis
+ 数据结构
+ C
+ 源码
+ Redis
+
+
+ redis
+ 数据结构
+ 源码
+
+
聊一下 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/
@@ -10326,94 +10395,6 @@ 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
-
-
聊聊 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/
@@ -11134,38 +11115,6 @@ public Result invoke(final Invocation invocation) throws RpcException {
自旋
-
- 聊聊 Java 的 equals 和 hashCode 方法
- /2021/01/03/%E8%81%8A%E8%81%8A-Java-%E7%9A%84-equals-%E5%92%8C-hashCode-%E6%96%B9%E6%B3%95/
- Java 中的这个话题也是比较常遇到的，关于这块原先也是比较忽略的，但是仔细想想又有点遗忘了就在这里记一下
简单看下代码
java.lang.Object#equals
-public boolean equals(Object obj) {
- return (this == obj);
- }
-对于所有对象的父类，equals 方法其实对比的就是对象的地址，也就是是否是同一个对象，试想如果像 Integer 或者 String 这种，我们没有重写 equals，那其实就等于是在用==，可能就没法达到我们的目的，所以像 String 这种常用的 jdk 类都是默认重写了
java.lang.String#equals
-public boolean equals(Object anObject) {
- if (this == anObject) {
- return true;
- }
- if (anObject instanceof String) {
- String anotherString = (String)anObject;
- int n = value.length;
- if (n == anotherString.value.length) {
- char v1[] = value;
- char v2[] = anotherString.value;
- int i = 0;
- while (n-- != 0) {
- if (v1[i] != v2[i])
- return false;
- i++;
- }
- return true;
- }
- }
- return false;
- }
-然后呢就是为啥一些书或者 effective java 中写了 equals 跟 hashCode 要一起重写，这里涉及到当对象作为 HashMap 的 key 的时候
首先 HashMap 会使用 hashCode 去判断是否在同一个槽里，然后在通过 equals 去判断是否是同一个 key，是的话就替换，不是的话就链表接下去，如果不重写 hashCode 的话，默认的 object 的hashCode 是 native 方法，根据对象的地址生成的，这样其实对象的值相同的话，因为地址不同，HashMap 也会出现异常，所以需要重写，同时也需要重写 equals 方法，才能确认是同一个 key，而不是落在同一个槽的不同 key.
-]]>
-
聊聊 Java 的类加载机制一
/2020/11/08/%E8%81%8A%E8%81%8A-Java-%E7%9A%84%E7%B1%BB%E5%8A%A0%E8%BD%BD%E6%9C%BA%E5%88%B6/
@@ -11204,6 +11153,38 @@ public Result invoke(final Invocation invocation) throws RpcException {
类加载
+
+ 聊聊 Java 的 equals 和 hashCode 方法
+ /2021/01/03/%E8%81%8A%E8%81%8A-Java-%E7%9A%84-equals-%E5%92%8C-hashCode-%E6%96%B9%E6%B3%95/
+ Java 中的这个话题也是比较常遇到的，关于这块原先也是比较忽略的，但是仔细想想又有点遗忘了就在这里记一下
简单看下代码
java.lang.Object#equals
+public boolean equals(Object obj) {
+ return (this == obj);
+ }
+对于所有对象的父类，equals 方法其实对比的就是对象的地址，也就是是否是同一个对象，试想如果像 Integer 或者 String 这种，我们没有重写 equals，那其实就等于是在用==，可能就没法达到我们的目的，所以像 String 这种常用的 jdk 类都是默认重写了
java.lang.String#equals
+public boolean equals(Object anObject) {
+ if (this == anObject) {
+ return true;
+ }
+ if (anObject instanceof String) {
+ String anotherString = (String)anObject;
+ int n = value.length;
+ if (n == anotherString.value.length) {
+ char v1[] = value;
+ char v2[] = anotherString.value;
+ int i = 0;
+ while (n-- != 0) {
+ if (v1[i] != v2[i])
+ return false;
+ i++;
+ }
+ return true;
+ }
+ }
+ return false;
+ }
+然后呢就是为啥一些书或者 effective java 中写了 equals 跟 hashCode 要一起重写，这里涉及到当对象作为 HashMap 的 key 的时候
首先 HashMap 会使用 hashCode 去判断是否在同一个槽里，然后在通过 equals 去判断是否是同一个 key，是的话就替换，不是的话就链表接下去，如果不重写 hashCode 的话，默认的 object 的hashCode 是 native 方法，根据对象的地址生成的，这样其实对象的值相同的话，因为地址不同，HashMap 也会出现异常，所以需要重写，同时也需要重写 equals 方法，才能确认是同一个 key，而不是落在同一个槽的不同 key.
+]]>
+
聊聊 Java 的类加载机制二
/2021/06/13/%E8%81%8A%E8%81%8A-Java-%E7%9A%84%E7%B1%BB%E5%8A%A0%E8%BD%BD%E6%9C%BA%E5%88%B6%E4%BA%8C/
@@ -11518,1702 +11499,1221 @@ public Result invoke(final Invocation invocation) throws RpcException {
- 聊聊 Linux 下的 top 命令
- /2021/03/28/%E8%81%8A%E8%81%8A-Linux-%E4%B8%8B%E7%9A%84-top-%E5%91%BD%E4%BB%A4/
- 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
+ 聊聊 Java 自带的那些*逆天*工具
+ /2020/08/02/%E8%81%8A%E8%81%8A-Java-%E8%87%AA%E5%B8%A6%E7%9A%84%E9%82%A3%E4%BA%9B%E9%80%86%E5%A4%A9%E5%B7%A5%E5%85%B7/
+ 原谅我的标题党，其实这些工具的确很厉害，之前其实介绍过一点相关的，是从我一次问题排查的过程中用到的，但是最近又有碰到一次排查问题，发现其实用 idea 直接 dump thread 是不现实的，毕竟服务器环境的没法这么操作，那就得用 Java 的那些工具了
+jstack & jps
譬如 jstack，这个命令其实不能更简单了
看看 help 信息
![]()
用-l参数可以打出锁的额外信息，然后后面的 pid 就是进程 id 咯，机智的小伙伴会问了（就你这个小白才问这么蠢的问题🤦♂️），怎么看 Java 应用的进程呢
那就是 jps 了，命令也很简单，一般直接用 jps命令就好了，不过也可以 help 看一下
![]()
稍微解释下，-q是只显示进程 id，-m是输出给main 方法的参数，比如我在配置中加给参数
![]()
然后用 jps -m查看
![]()
-v加上小 v 的话就是打印 jvm 参数
![]()
还是有点东西，然后就继续介绍 jstack 了，然后我们看看 jstack 出来是啥，为了加点内容我加了个死锁
+public static void main(String[] args) throws InterruptedException {
+ SpringApplication.run(ThreadDumpDemoApplication.class, args);
+ ReentrantLock lock1 = new ReentrantLock();
+ ReentrantLock lock2 = new ReentrantLock();
+ Thread t1 = new Thread() {
+ @Override
+ public void run() {
+ try {
+ lock1.lock();
+ TimeUnit.SECONDS.sleep(1);
+ lock2.lock();
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ }
+ };
+ Thread t2 = new Thread() {
+ @Override
+ public void run() {
+ try {
+ lock2.lock();
+ TimeUnit.SECONDS.sleep(1);
+ lock1.lock();
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ }
+ };
+ t1.setName("mythread1");
+ t2.setName("mythread2");
+ t1.start();
+ t2.start();
+ Thread.sleep(10000);
+ }
+然后看看出来时怎么样的
+2020-08-02 21:50:32
+Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):
- For compatibility, this top supports most of the former top sort keys. Since this is primarily a service to former top users, these commands
- do not appear on any help screen.
- command sorted-field supported
- A start time (non-display) No
- M %MEM Yes
- N PID Yes
- P %CPU Yes
- T TIME+ Yes
+"DestroyJavaVM" #147 prio=5 os_prio=31 tid=0x00007fc9dd807000 nid=0x2603 waiting on condition [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
- Before using any of the following sort provisions, top suggests that you temporarily turn on column highlighting using the `x' interactive com‐
- mand. That will help ensure that the actual sort environment matches your intent.
+ Locked ownable synchronizers:
+ - None
- The following interactive commands will only be honored when the current sort field is visible. The sort field might not be visible because:
- 1) there is insufficient Screen Width
- 2) the `f' interactive command turned it Off
+"mythread2" #140 prio=5 os_prio=31 tid=0x00007fc9dd877000 nid=0x9903 waiting on condition [0x0000700006fb9000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f5d4330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
+ at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
+ at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
+ at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$2.run(ThreadDumpDemoApplication.java:34)
- < :Move-Sort-Field-Left
- Moves the sort column to the left unless the current sort field is the first field being displayed.
+ Locked ownable synchronizers:
+ - <0x000000076f5d4360> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- > :Move-Sort-Field-Right
- Moves the sort column to the right unless the current sort field is the last field being displayed.
-查看 man page 可以找到这一段，其实一般 man page 都是最细致的，只不过因为太多了，有时候懒得看，这里可以通过大写 M 和大写 P 分别按内存和 CPU 排序，下面还有两个小技巧，通过按 x 可以将当前活跃的排序列用不同颜色标出来，然后可以通过<和>直接左右移动排序列
-]]>
-
- Linux
- 小技巧
- 命令
- top
- top
- 排序
-
-
- 排序
- linux
- 小技巧
- top
-
-
-
- 聊聊 RocketMQ 的 Broker 源码
- /2020/07/19/%E8%81%8A%E8%81%8A-RocketMQ-%E7%9A%84-Broker-%E6%BA%90%E7%A0%81/
- broker 的启动形式有点类似于 NameServer，都是服务类型的，跟 Consumer 差别比较大，
-首先是org.apache.rocketmq.broker.BrokerStartup中的 main 函数，org.apache.rocketmq.broker.BrokerStartup#createBrokerController基本就是读取参数，这里差点把最核心的初始化给漏了，
-final BrokerController controller = new BrokerController(
- brokerConfig,
- nettyServerConfig,
- nettyClientConfig,
- messageStoreConfig);
- // remember all configs to prevent discard
- controller.getConfiguration().registerConfig(properties);
+"mythread1" #139 prio=5 os_prio=31 tid=0x00007fc9de873800 nid=0x9a03 waiting on condition [0x0000700006eb6000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f5d4360> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
+ at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
+ at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
+ at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$1.run(ThreadDumpDemoApplication.java:22)
- boolean initResult = controller.initialize();
+ Locked ownable synchronizers:
+ - <0x000000076f5d4330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
-前面是以 broker 配置，netty 的服务端和客户端配置，以及消息存储配置在实例化 BrokerController，然后就是初始化了
-public boolean initialize() throws CloneNotSupportedException {
- boolean result = this.topicConfigManager.load();
+"http-nio-8080-Acceptor" #137 daemon prio=5 os_prio=31 tid=0x00007fc9de1ac000 nid=0x9b03 runnable [0x0000700006db3000]
+ java.lang.Thread.State: RUNNABLE
+ at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
+ at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
+ at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
+ - locked <0x000000076f1e4820> (a java.lang.Object)
+ at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:469)
+ at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:71)
+ at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:95)
+ at java.lang.Thread.run(Thread.java:748)
- result = result && this.consumerOffsetManager.load();
- result = result && this.subscriptionGroupManager.load();
- result = result && this.consumerFilterManager.load();
+ Locked ownable synchronizers:
+ - None
-前面这些就是各个配置的 load 了，然后是个我认为比较重要的部分messageStore 的实例化，
-if (result) {
- try {
- this.messageStore =
- new DefaultMessageStore(this.messageStoreConfig, this.brokerStatsManager, this.messageArrivingListener,
- this.brokerConfig);
- if (messageStoreConfig.isEnableDLegerCommitLog()) {
- DLedgerRoleChangeHandler roleChangeHandler = new DLedgerRoleChangeHandler(this, (DefaultMessageStore) messageStore);
- ((DLedgerCommitLog)((DefaultMessageStore) messageStore).getCommitLog()).getdLedgerServer().getdLedgerLeaderElector().addRoleChangeHandler(roleChangeHandler);
- }
- this.brokerStats = new BrokerStats((DefaultMessageStore) this.messageStore);
- //load plugin
- MessageStorePluginContext context = new MessageStorePluginContext(messageStoreConfig, brokerStatsManager, messageArrivingListener, brokerConfig);
- this.messageStore = MessageStoreFactory.build(context, this.messageStore);
- this.messageStore.getDispatcherList().addFirst(new CommitLogDispatcherCalcBitMap(this.brokerConfig, this.consumerFilterManager));
- } catch (IOException e) {
- result = false;
- log.error("Failed to initialize", e);
- }
-}
+"http-nio-8080-ClientPoller" #136 daemon prio=5 os_prio=31 tid=0x00007fc9dd876800 nid=0x6503 runnable [0x0000700006cb0000]
+ java.lang.Thread.State: RUNNABLE
+ at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
+ at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
+ at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
+ at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
+ - locked <0x000000076f2978c8> (a sun.nio.ch.Util$3)
+ - locked <0x000000076f2978b8> (a java.util.Collections$UnmodifiableSet)
+ - locked <0x000000076f297798> (a sun.nio.ch.KQueueSelectorImpl)
+ at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
+ at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:709)
+ at java.lang.Thread.run(Thread.java:748)
-result = result && this.messageStore.load();
+ Locked ownable synchronizers:
+ - None
-先是实例化，实例化构造函数里的代码比较重要，重点看一下
-public DefaultMessageStore(final MessageStoreConfig messageStoreConfig, final BrokerStatsManager brokerStatsManager,
- final MessageArrivingListener messageArrivingListener, final BrokerConfig brokerConfig) throws IOException {
- this.messageArrivingListener = messageArrivingListener;
- this.brokerConfig = brokerConfig;
- this.messageStoreConfig = messageStoreConfig;
- this.brokerStatsManager = brokerStatsManager;
- this.allocateMappedFileService = new AllocateMappedFileService(this);
- if (messageStoreConfig.isEnableDLegerCommitLog()) {
- this.commitLog = new DLedgerCommitLog(this);
- } else {
- this.commitLog = new CommitLog(this);
- }
- this.consumeQueueTable = new ConcurrentHashMap<>(32);
+"http-nio-8080-exec-10" #135 daemon prio=5 os_prio=31 tid=0x00007fc9de1af000 nid=0x9d03 waiting on condition [0x0000700006bad000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.flushConsumeQueueService = new FlushConsumeQueueService();
- this.cleanCommitLogService = new CleanCommitLogService();
- this.cleanConsumeQueueService = new CleanConsumeQueueService();
- this.storeStatsService = new StoreStatsService();
- this.indexService = new IndexService(this);
- if (!messageStoreConfig.isEnableDLegerCommitLog()) {
- this.haService = new HAService(this);
- } else {
- this.haService = null;
- }
- this.reputMessageService = new ReputMessageService();
+ Locked ownable synchronizers:
+ - None
- this.scheduleMessageService = new ScheduleMessageService(this);
+"http-nio-8080-exec-9" #134 daemon prio=5 os_prio=31 tid=0x00007fc9de1ab800 nid=0x6403 waiting on condition [0x0000700006aaa000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.transientStorePool = new TransientStorePool(messageStoreConfig);
+ Locked ownable synchronizers:
+ - None
- if (messageStoreConfig.isTransientStorePoolEnable()) {
- this.transientStorePool.init();
- }
+"http-nio-8080-exec-8" #133 daemon prio=5 os_prio=31 tid=0x00007fc9de873000 nid=0x9f03 waiting on condition [0x00007000069a7000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.allocateMappedFileService.start();
+ Locked ownable synchronizers:
+ - None
- this.indexService.start();
+"http-nio-8080-exec-7" #132 daemon prio=5 os_prio=31 tid=0x00007fc9df0a1800 nid=0xa103 waiting on condition [0x00007000068a4000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.dispatcherList = new LinkedList<>();
- this.dispatcherList.addLast(new CommitLogDispatcherBuildConsumeQueue());
- this.dispatcherList.addLast(new CommitLogDispatcherBuildIndex());
+ Locked ownable synchronizers:
+ - None
- File file = new File(StorePathConfigHelper.getLockFile(messageStoreConfig.getStorePathRootDir()));
- MappedFile.ensureDirOK(file.getParent());
- lockFile = new RandomAccessFile(file, "rw");
- }
+"http-nio-8080-exec-6" #131 daemon prio=5 os_prio=31 tid=0x00007fc9df242800 nid=0x6103 waiting on condition [0x00007000067a1000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
-这里面有很多类，不过先把从构造函数里传进来的忽略下，接下来就是 AllocateMappedFileService 这个service，前面看过文章的可能会根据上面的代码猜到，这也是个 ServiceThread，如果是对RocketMQ 有所了解的可能从名字可以看出这个类是关于 RocketMQ 消息怎么落盘的，当需要创建MappedFile时（在MapedFileQueue.getLastMapedFile方法中），向该线程的requestQueue队列中放入AllocateRequest请求对象，该线程会在后台监听该队列，并在后台创建MapedFile对象，即同时创建了物理文件。然后是创建了 IndexService 服务线程，用来给创建索引；还有是FlushConsumeQueueService是将ConsumeQueue 刷入磁盘；CleanCommitLogService用来清理过期的 CommitLog，默认是 72 小时以上；CleanConsumeQueueService是将小于最新的 CommitLog 偏移量的 ConsumeQueue 清理掉；StoreStatsService是储存统计服务；HAService用于CommitLog 的主备同步；ScheduleMessageService用于定时消息；还有就是这个ReputMessageService非常重要，就是由它实现了将 CommitLog 以 topic+queue 纬度构建 ConsumeQueue，后面TransientStorePool是异步刷盘时的存储buffer，也可以从后面的判断中看出来
-public boolean isTransientStorePoolEnable() {
- return transientStorePoolEnable && FlushDiskType.ASYNC_FLUSH == getFlushDiskType()
- && BrokerRole.SLAVE != getBrokerRole();
- }
+ Locked ownable synchronizers:
+ - None
-再然后就是启动两个服务线程，dispatcherList是为CommitLog文件转发请求，差不多这个初始化就这些内容。
-然后回到外层，下面是主备切换的配置，然后是数据统计，接着是存储插件加载，然后是往转发器链表里再加一个过滤器
-if (messageStoreConfig.isEnableDLegerCommitLog()) {
- DLedgerRoleChangeHandler roleChangeHandler = new DLedgerRoleChangeHandler(this, (DefaultMessageStore) messageStore);
- ((DLedgerCommitLog)((DefaultMessageStore) messageStore).getCommitLog()).getdLedgerServer().getdLedgerLeaderElector().addRoleChangeHandler(roleChangeHandler);
- }
- this.brokerStats = new BrokerStats((DefaultMessageStore) this.messageStore);
- //load plugin
- MessageStorePluginContext context = new MessageStorePluginContext(messageStoreConfig, brokerStatsManager, messageArrivingListener, brokerConfig);
- this.messageStore = MessageStoreFactory.build(context, this.messageStore);
- this.messageStore.getDispatcherList().addFirst(new CommitLogDispatcherCalcBitMap(this.brokerConfig, this.consumerFilterManager));
+"http-nio-8080-exec-5" #130 daemon prio=5 os_prio=31 tid=0x00007fc9de872000 nid=0x5f03 waiting on condition [0x000070000669e000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
-接下来就是org.apache.rocketmq.store.MessageStore#load的过程了，
-
-- 调用ScheduleMessageService.load方法，初始化延迟级别列表。将这些级别（”1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”）的延时存入延迟级别delayLevelTable：ConcurrentHashMap<Integer /* level */, Long/* delay timeMillis */>变量中，例如1s的kv值为1:1000,5s的kv值为2:5000，key值依次类推；每个延迟级别即为一个队列。
-
-2)调用CommitLog.load方法，在此方法中调用MapedFileQueue.load方法，将$HOME /store/commitlog目录下的所有文件加载到MapedFileQueue的List变量中；
-3)调用DefaultMessageStore.loadConsumeQueue方法加载consumequeue文件数据到DefaultMessageStore.consumeQueueTable集合中。
-初始化StoreCheckPoint对象，加载$HOME/store/checkpoint文件，该文件记录三个字段值，分别是物理队列消息时间戳、逻辑队列消息时间戳、索引队列消息时间戳。
-调用IndexService.load方法加载$HOME/store/index目录下的文件。对该目录下的每个文件初始化一个IndexFile对象。然后调用IndexFile对象的load方法将IndexHeader加载到对象的变量中；再根据检查是否存在abort文件，若有存在abort文件，则表示Broker表示上次是异常退出的，则检查checkpoint的indexMsgTimestamp字段值是否小于IndexHeader的endTimestamp值，indexMsgTimestamp值表示最后刷盘的时间，若小于则表示在最后刷盘之后在该文件中还创建了索引，则要删除该Index文件，否则将该IndexFile对象放入indexFileList:ArrayList索引文件集合中。
-然后调用org.apache.rocketmq.store.DefaultMessageStore#recover恢复，前面有根据boolean lastExitOK = !this.isTempFileExist();临时文件是否存在来判断上一次是否正常退出，根据这个状态来选择什么恢复策略
-接下去是初始化 Netty 服务端，初始化发送消息线程池（sendMessageExecutor）、拉取消息线程池（pullMessageExecutor）、管理Broker线程池（adminBrokerExecutor）、客户端管理线程池（clientManageExecutor），注册事件处理器，包括发送消息事件处理器（SendMessageProcessor）、拉取消息事件处理器、查询消息事件处理器（QueryMessageProcessor，包括客户端的心跳事件、注销事件、获取消费者列表事件、更新更新和查询消费进度consumerOffset）、客户端管理事件处理器（ClientManageProcessor）、结束事务处理器（EndTransactionProcessor）、默认事件处理器（AdminBrokerProcessor），然后是定时任务
-BrokerController.this.getBrokerStats().record(); 记录 Broker 状态
-BrokerController.this.consumerOffsetManager.persist(); 持久化consumerOffset
-BrokerController.this.consumerFilterManager.persist();持久化consumerFilter
-BrokerController.this.protectBroker(); 保护 broker，消费慢，不让继续投递
-BrokerController.this.printWaterMark(); 打印水位
-log.info("dispatch behind commit log {} bytes", BrokerController.this.getMessageStore().dispatchBehindBytes()); 检查落后程度
-BrokerController.this.brokerOuterAPI.fetchNameServerAddr(); 定时获取 nameserver
-BrokerController.this.printMasterAndSlaveDiff(); 打印主从不一致
-然后是 tsl，初始化事务消息，初始化 RPCHook
-请把害怕打到公屏上🤦♂️，从线程池名字和调用的方法应该可以看出大部分的用途
-this.remotingServer = new NettyRemotingServer(this.nettyServerConfig, this.clientHousekeepingService);
- NettyServerConfig fastConfig = (NettyServerConfig) this.nettyServerConfig.clone();
- fastConfig.setListenPort(nettyServerConfig.getListenPort() - 2);
- this.fastRemotingServer = new NettyRemotingServer(fastConfig, this.clientHousekeepingService);
- this.sendMessageExecutor = new BrokerFixedThreadPoolExecutor(
- this.brokerConfig.getSendMessageThreadPoolNums(),
- this.brokerConfig.getSendMessageThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.sendThreadPoolQueue,
- new ThreadFactoryImpl("SendMessageThread_"));
+ Locked ownable synchronizers:
+ - None
- this.pullMessageExecutor = new BrokerFixedThreadPoolExecutor(
- this.brokerConfig.getPullMessageThreadPoolNums(),
- this.brokerConfig.getPullMessageThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.pullThreadPoolQueue,
- new ThreadFactoryImpl("PullMessageThread_"));
+"http-nio-8080-exec-4" #129 daemon prio=5 os_prio=31 tid=0x00007fc9de1a6000 nid=0x5e03 waiting on condition [0x000070000659b000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.replyMessageExecutor = new BrokerFixedThreadPoolExecutor(
- this.brokerConfig.getProcessReplyMessageThreadPoolNums(),
- this.brokerConfig.getProcessReplyMessageThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.replyThreadPoolQueue,
- new ThreadFactoryImpl("ProcessReplyMessageThread_"));
+ Locked ownable synchronizers:
+ - None
- this.queryMessageExecutor = new BrokerFixedThreadPoolExecutor(
- this.brokerConfig.getQueryMessageThreadPoolNums(),
- this.brokerConfig.getQueryMessageThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.queryThreadPoolQueue,
- new ThreadFactoryImpl("QueryMessageThread_"));
+"http-nio-8080-exec-3" #128 daemon prio=5 os_prio=31 tid=0x00007fc9de871800 nid=0x5c03 waiting on condition [0x0000700006498000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.adminBrokerExecutor =
- Executors.newFixedThreadPool(this.brokerConfig.getAdminBrokerThreadPoolNums(), new ThreadFactoryImpl(
- "AdminBrokerThread_"));
+ Locked ownable synchronizers:
+ - None
- this.clientManageExecutor = new ThreadPoolExecutor(
- this.brokerConfig.getClientManageThreadPoolNums(),
- this.brokerConfig.getClientManageThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.clientManagerThreadPoolQueue,
- new ThreadFactoryImpl("ClientManageThread_"));
+"http-nio-8080-exec-2" #127 daemon prio=5 os_prio=31 tid=0x00007fc9dead9000 nid=0x5b03 waiting on condition [0x0000700006395000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.heartbeatExecutor = new BrokerFixedThreadPoolExecutor(
- this.brokerConfig.getHeartbeatThreadPoolNums(),
- this.brokerConfig.getHeartbeatThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.heartbeatThreadPoolQueue,
- new ThreadFactoryImpl("HeartbeatThread_", true));
+ Locked ownable synchronizers:
+ - None
- this.endTransactionExecutor = new BrokerFixedThreadPoolExecutor(
- this.brokerConfig.getEndTransactionThreadPoolNums(),
- this.brokerConfig.getEndTransactionThreadPoolNums(),
- 1000 * 60,
- TimeUnit.MILLISECONDS,
- this.endTransactionThreadPoolQueue,
- new ThreadFactoryImpl("EndTransactionThread_"));
+"http-nio-8080-exec-1" #126 daemon prio=5 os_prio=31 tid=0x00007fc9ddb00000 nid=0x5a03 waiting on condition [0x0000700006292000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
+ at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.consumerManageExecutor =
- Executors.newFixedThreadPool(this.brokerConfig.getConsumerManageThreadPoolNums(), new ThreadFactoryImpl(
- "ConsumerManageThread_"));
+ Locked ownable synchronizers:
+ - None
- this.registerProcessor();
+"http-nio-8080-BlockPoller" #125 daemon prio=5 os_prio=31 tid=0x00007fc9df242000 nid=0xa503 runnable [0x000070000618f000]
+ java.lang.Thread.State: RUNNABLE
+ at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
+ at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
+ at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
+ at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
+ - locked <0x000000076f1eea30> (a sun.nio.ch.Util$3)
+ - locked <0x000000076f1ee198> (a java.util.Collections$UnmodifiableSet)
+ - locked <0x000000076f1ee010> (a sun.nio.ch.KQueueSelectorImpl)
+ at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
+ at org.apache.tomcat.util.net.NioBlockingSelector$BlockPoller.run(NioBlockingSelector.java:313)
- final long initialDelay = UtilAll.computeNextMorningTimeMillis() - System.currentTimeMillis();
- final long period = 1000 * 60 * 60 * 24;
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- try {
- BrokerController.this.getBrokerStats().record();
- } catch (Throwable e) {
- log.error("schedule record error.", e);
- }
- }
- }, initialDelay, period, TimeUnit.MILLISECONDS);
+ Locked ownable synchronizers:
+ - None
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- try {
- BrokerController.this.consumerOffsetManager.persist();
- } catch (Throwable e) {
- log.error("schedule persist consumerOffset error.", e);
- }
- }
- }, 1000 * 10, this.brokerConfig.getFlushConsumerOffsetInterval(), TimeUnit.MILLISECONDS);
+"container-0" #124 prio=5 os_prio=31 tid=0x00007fc9df06a000 nid=0x5803 waiting on condition [0x000070000608c000]
+ java.lang.Thread.State: TIMED_WAITING (sleeping)
+ at java.lang.Thread.sleep(Native Method)
+ at org.apache.catalina.core.StandardServer.await(StandardServer.java:570)
+ at org.springframework.boot.web.embedded.tomcat.TomcatWebServer$1.run(TomcatWebServer.java:197)
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- try {
- BrokerController.this.consumerFilterManager.persist();
- } catch (Throwable e) {
- log.error("schedule persist consumer filter error.", e);
- }
- }
- }, 1000 * 10, 1000 * 10, TimeUnit.MILLISECONDS);
+ Locked ownable synchronizers:
+ - None
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- try {
- BrokerController.this.protectBroker();
- } catch (Throwable e) {
- log.error("protectBroker error.", e);
- }
- }
- }, 3, 3, TimeUnit.MINUTES);
+"Catalina-utility-2" #123 prio=1 os_prio=31 tid=0x00007fc9de886000 nid=0xa80f waiting on condition [0x0000700005f89000]
+ java.lang.Thread.State: WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076c88ab58> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
+ at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
+ at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- try {
- BrokerController.this.printWaterMark();
- } catch (Throwable e) {
- log.error("printWaterMark error.", e);
- }
- }
- }, 10, 1, TimeUnit.SECONDS);
+ Locked ownable synchronizers:
+ - None
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+"Catalina-utility-1" #122 prio=1 os_prio=31 tid=0x00007fc9de884000 nid=0x5667 waiting on condition [0x0000700005e86000]
+ java.lang.Thread.State: TIMED_WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076c88ab58> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
+ at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
+ at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
+ at java.lang.Thread.run(Thread.java:748)
- @Override
- public void run() {
- try {
- log.info("dispatch behind commit log {} bytes", BrokerController.this.getMessageStore().dispatchBehindBytes());
- } catch (Throwable e) {
- log.error("schedule dispatchBehindBytes error.", e);
- }
- }
- }, 1000 * 10, 1000 * 60, TimeUnit.MILLISECONDS);
+ Locked ownable synchronizers:
+ - None
- if (this.brokerConfig.getNamesrvAddr() != null) {
- this.brokerOuterAPI.updateNameServerAddressList(this.brokerConfig.getNamesrvAddr());
- log.info("Set user specified name server address: {}", this.brokerConfig.getNamesrvAddr());
- } else if (this.brokerConfig.isFetchNamesrvAddrByAddressServer()) {
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+"RMI Scheduler(0)" #15 daemon prio=5 os_prio=31 tid=0x00007fc9de9ee000 nid=0x5503 waiting on condition [0x0000700005d83000]
+ java.lang.Thread.State: TIMED_WAITING (parking)
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x00000006c0015410> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
+ at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
+ at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
+ at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
+ at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
+ at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
+ at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
+ at java.lang.Thread.run(Thread.java:748)
- @Override
- public void run() {
- try {
- BrokerController.this.brokerOuterAPI.fetchNameServerAddr();
- } catch (Throwable e) {
- log.error("ScheduledTask fetchNameServerAddr exception", e);
- }
- }
- }, 1000 * 10, 1000 * 60 * 2, TimeUnit.MILLISECONDS);
- }
+ Locked ownable synchronizers:
+ - None
- if (!messageStoreConfig.isEnableDLegerCommitLog()) {
- if (BrokerRole.SLAVE == this.messageStoreConfig.getBrokerRole()) {
- if (this.messageStoreConfig.getHaMasterAddress() != null && this.messageStoreConfig.getHaMasterAddress().length() >= 6) {
- this.messageStore.updateHaMasterAddress(this.messageStoreConfig.getHaMasterAddress());
- this.updateMasterHAServerAddrPeriodically = false;
- } else {
- this.updateMasterHAServerAddrPeriodically = true;
- }
- } else {
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- @Override
- public void run() {
- try {
- BrokerController.this.printMasterAndSlaveDiff();
- } catch (Throwable e) {
- log.error("schedule printMasterAndSlaveDiff error.", e);
- }
- }
- }, 1000 * 10, 1000 * 60, TimeUnit.MILLISECONDS);
- }
- }
+"Attach Listener" #13 daemon prio=9 os_prio=31 tid=0x00007fc9df149800 nid=0x3c07 waiting on condition [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
- if (TlsSystemConfig.tlsMode != TlsMode.DISABLED) {
- // Register a listener to reload SslContext
- try {
- fileWatchService = new FileWatchService(
- new String[] {
- TlsSystemConfig.tlsServerCertPath,
- TlsSystemConfig.tlsServerKeyPath,
- TlsSystemConfig.tlsServerTrustCertPath
- },
- new FileWatchService.Listener() {
- boolean certChanged, keyChanged = false;
+ Locked ownable synchronizers:
+ - None
- @Override
- public void onChanged(String path) {
- if (path.equals(TlsSystemConfig.tlsServerTrustCertPath)) {
- log.info("The trust certificate changed, reload the ssl context");
- reloadServerSslContext();
- }
- if (path.equals(TlsSystemConfig.tlsServerCertPath)) {
- certChanged = true;
- }
- if (path.equals(TlsSystemConfig.tlsServerKeyPath)) {
- keyChanged = true;
- }
- if (certChanged && keyChanged) {
- log.info("The certificate and private key changed, reload the ssl context");
- certChanged = keyChanged = false;
- reloadServerSslContext();
- }
- }
+"RMI TCP Accept-0" #11 daemon prio=5 os_prio=31 tid=0x00007fc9df100000 nid=0x4003 runnable [0x0000700005977000]
+ java.lang.Thread.State: RUNNABLE
+ at java.net.PlainSocketImpl.socketAccept(Native Method)
+ at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
+ at java.net.ServerSocket.implAccept(ServerSocket.java:545)
+ at java.net.ServerSocket.accept(ServerSocket.java:513)
+ at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)
+ at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:405)
+ at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:377)
+ at java.lang.Thread.run(Thread.java:748)
- private void reloadServerSslContext() {
- ((NettyRemotingServer) remotingServer).loadSslContext();
- ((NettyRemotingServer) fastRemotingServer).loadSslContext();
- }
- });
- } catch (Exception e) {
- log.warn("FileWatchService created error, can't load the certificate dynamically");
- }
- }
- initialTransaction();
- initialAcl();
- initialRpcHooks();
- }
- return result;
+ Locked ownable synchronizers:
+ - None
+"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fc9df0ce800 nid=0x4103 runnable [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
+ Locked ownable synchronizers:
+ - None
-Broker 启动过程
-贴代码
-public void start() throws Exception {
- if (this.messageStore != null) {
- this.messageStore.start();
- }
+"C1 CompilerThread2" #8 daemon prio=9 os_prio=31 tid=0x00007fc9df0ce000 nid=0x4203 waiting on condition [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
- if (this.remotingServer != null) {
- this.remotingServer.start();
- }
+ Locked ownable synchronizers:
+ - None
- if (this.fastRemotingServer != null) {
- this.fastRemotingServer.start();
- }
+"C2 CompilerThread1" #7 daemon prio=9 os_prio=31 tid=0x00007fc9de0a3800 nid=0x3503 waiting on condition [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
- if (this.fileWatchService != null) {
- this.fileWatchService.start();
- }
+ Locked ownable synchronizers:
+ - None
- if (this.brokerOuterAPI != null) {
- this.brokerOuterAPI.start();
- }
+"C2 CompilerThread0" #6 daemon prio=9 os_prio=31 tid=0x00007fc9de89b000 nid=0x3403 waiting on condition [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
- if (this.pullRequestHoldService != null) {
- this.pullRequestHoldService.start();
- }
+ Locked ownable synchronizers:
+ - None
- if (this.clientHousekeepingService != null) {
- this.clientHousekeepingService.start();
- }
+"Monitor Ctrl-Break" #5 daemon prio=5 os_prio=31 tid=0x00007fc9df0ca000 nid=0x3303 runnable [0x0000700005468000]
+ java.lang.Thread.State: RUNNABLE
+ at java.net.SocketInputStream.socketRead0(Native Method)
+ at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
+ at java.net.SocketInputStream.read(SocketInputStream.java:171)
+ at java.net.SocketInputStream.read(SocketInputStream.java:141)
+ at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
+ at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
+ at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
+ - locked <0x00000006c001b760> (a java.io.InputStreamReader)
+ at java.io.InputStreamReader.read(InputStreamReader.java:184)
+ at java.io.BufferedReader.fill(BufferedReader.java:161)
+ at java.io.BufferedReader.readLine(BufferedReader.java:324)
+ - locked <0x00000006c001b760> (a java.io.InputStreamReader)
+ at java.io.BufferedReader.readLine(BufferedReader.java:389)
+ at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)
- if (this.filterServerManager != null) {
- this.filterServerManager.start();
- }
+ Locked ownable synchronizers:
+ - None
- if (!messageStoreConfig.isEnableDLegerCommitLog()) {
- startProcessorByHa(messageStoreConfig.getBrokerRole());
- handleSlaveSynchronize(messageStoreConfig.getBrokerRole());
- this.registerBrokerAll(true, false, true);
- }
+"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fc9de824000 nid=0x4503 runnable [0x0000000000000000]
+ java.lang.Thread.State: RUNNABLE
- this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ Locked ownable synchronizers:
+ - None
- @Override
- public void run() {
- try {
- BrokerController.this.registerBrokerAll(true, false, brokerConfig.isForceRegister());
- } catch (Throwable e) {
- log.error("registerBrokerAll Exception", e);
- }
- }
- }, 1000 * 10, Math.max(10000, Math.min(brokerConfig.getRegisterNameServerPeriod(), 60000)), TimeUnit.MILLISECONDS);
+"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fc9dd811800 nid=0x4f03 in Object.wait() [0x0000700005262000]
+ java.lang.Thread.State: WAITING (on object monitor)
+ at java.lang.Object.wait(Native Method)
+ - waiting on <0x00000006c0008348> (a java.lang.ref.ReferenceQueue$Lock)
+ at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
+ - locked <0x00000006c0008348> (a java.lang.ref.ReferenceQueue$Lock)
+ at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
+ at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
- if (this.brokerStatsManager != null) {
- this.brokerStatsManager.start();
- }
+ Locked ownable synchronizers:
+ - None
- if (this.brokerFastFailure != null) {
- this.brokerFastFailure.start();
- }
+"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fc9de02a000 nid=0x5003 in Object.wait() [0x000070000515f000]
+ java.lang.Thread.State: WAITING (on object monitor)
+ at java.lang.Object.wait(Native Method)
+ - waiting on <0x00000006c001b940> (a java.lang.ref.Reference$Lock)
+ at java.lang.Object.wait(Object.java:502)
+ at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
+ - locked <0x00000006c001b940> (a java.lang.ref.Reference$Lock)
+ at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
+ Locked ownable synchronizers:
+ - None
- }
+"VM Thread" os_prio=31 tid=0x00007fc9df00b800 nid=0x2c03 runnable
-首先是启动messageStore，调用 start 方法，这里面又调用了一些代码
-public void start() throws Exception {
+"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fc9de805000 nid=0x1e07 runnable
- lock = lockFile.getChannel().tryLock(0, 1, false);
- if (lock == null || lock.isShared() || !lock.isValid()) {
- throw new RuntimeException("Lock failed,MQ already started");
- }
+"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fc9de003800 nid=0x2a03 runnable
- lockFile.getChannel().write(ByteBuffer.wrap("lock".getBytes()));
- lockFile.getChannel().force(true);
- {
- /**
- * 1. Make sure the fast-forward messages to be truncated during the recovering according to the max physical offset of the commitlog;
- * 2. DLedger committedPos may be missing, so the maxPhysicalPosInLogicQueue maybe bigger that maxOffset returned by DLedgerCommitLog, just let it go;
- * 3. Calculate the reput offset according to the consume queue;
- * 4. Make sure the fall-behind messages to be dispatched before starting the commitlog, especially when the broker role are automatically changed.
- */
- long maxPhysicalPosInLogicQueue = commitLog.getMinOffset();
- for (ConcurrentMap<Integer, ConsumeQueue> maps : this.consumeQueueTable.values()) {
- for (ConsumeQueue logic : maps.values()) {
- if (logic.getMaxPhysicOffset() > maxPhysicalPosInLogicQueue) {
- maxPhysicalPosInLogicQueue = logic.getMaxPhysicOffset();
- }
- }
- }
- if (maxPhysicalPosInLogicQueue < 0) {
- maxPhysicalPosInLogicQueue = 0;
- }
- if (maxPhysicalPosInLogicQueue < this.commitLog.getMinOffset()) {
- maxPhysicalPosInLogicQueue = this.commitLog.getMinOffset();
- /**
- * This happens in following conditions:
- * 1. If someone removes all the consumequeue files or the disk get damaged.
- * 2. Launch a new broker, and copy the commitlog from other brokers.
- *
- * All the conditions has the same in common that the maxPhysicalPosInLogicQueue should be 0.
- * If the maxPhysicalPosInLogicQueue is gt 0, there maybe something wrong.
- */
- log.warn("[TooSmallCqOffset] maxPhysicalPosInLogicQueue={} clMinOffset={}", maxPhysicalPosInLogicQueue, this.commitLog.getMinOffset());
- }
- log.info("[SetReputOffset] maxPhysicalPosInLogicQueue={} clMinOffset={} clMaxOffset={} clConfirmedOffset={}",
- maxPhysicalPosInLogicQueue, this.commitLog.getMinOffset(), this.commitLog.getMaxOffset(), this.commitLog.getConfirmOffset());
- this.reputMessageService.setReputFromOffset(maxPhysicalPosInLogicQueue);
- this.reputMessageService.start();
+"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fc9df002000 nid=0x5403 runnable
- /**
- * 1. Finish dispatching the messages fall behind, then to start other services.
- * 2. DLedger committedPos may be missing, so here just require dispatchBehindBytes <= 0
- */
- while (true) {
- if (dispatchBehindBytes() <= 0) {
- break;
- }
- Thread.sleep(1000);
- log.info("Try to finish doing reput the messages fall behind during the starting, reputOffset={} maxOffset={} behind={}", this.reputMessageService.getReputFromOffset(), this.getMaxPhyOffset(), this.dispatchBehindBytes());
- }
- this.recoverTopicQueueTable();
- }
+"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fc9df002800 nid=0x5203 runnable
- if (!messageStoreConfig.isEnableDLegerCommitLog()) {
- this.haService.start();
- this.handleScheduleMessageService(messageStoreConfig.getBrokerRole());
- }
+"VM Periodic Task Thread" os_prio=31 tid=0x00007fc9df11a800 nid=0x3a03 waiting on condition
- this.flushConsumeQueueService.start();
- this.commitLog.start();
- this.storeStatsService.start();
+JNI global references: 1087
- this.createTempFile();
- this.addScheduleTask();
- this.shutdown = false;
- }
+Found one Java-level deadlock:
+=============================
+"mythread2":
+ waiting for ownable synchronizer 0x000000076f5d4330, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
+ which is held by "mythread1"
+"mythread1":
+ waiting for ownable synchronizer 0x000000076f5d4360, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
+ which is held by "mythread2"
+Java stack information for the threads listed above:
+===================================================
+"mythread2":
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f5d4330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
+ at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
+ at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
+ at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$2.run(ThreadDumpDemoApplication.java:34)
+"mythread1":
+ at sun.misc.Unsafe.park(Native Method)
+ - parking to wait for <0x000000076f5d4360> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
+ at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
+ at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
+ at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
+ at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
+ at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$1.run(ThreadDumpDemoApplication.java:22)
-调用DefaultMessageStore.start方法启动DefaultMessageStore对象中的一些服务线程。
-
-- 启动ReputMessageService服务线程
-- 启动FlushConsumeQueueService服务线程；
-- 调用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，基本上启动过程就完成了
+Found 1 deadlock.
+前面的信息其实上次就看过了，后面就可以发现有个死锁了，
![]()
上面比较长，把主要的截出来，就是这边的，这点就很强大了。
+jmap
惯例还是看一下帮助信息
![]()
这个相对命令比较多，不过因为现在 dump 下来我们可能会用文件模式，然后将文件下载下来使用 mat 进行分析，所以可以使用
jmap -dump:live,format=b,file=heap.bin <pid>
命令照着上面看的就是打印活着的对象，然后以二进制格式，文件名叫 heap.bin 然后最后就是进程 id，打印出来以后可以用 mat 打开
![]()
这样就可以很清晰的看到应用里的各种信息，jmap 直接在命令中还可以看很多信息，比如使用jmap -histo <pid>打印对象的实例数和对象占用的内存
![]()
jmap -finalizerinfo <pid> 打印正在等候回收的对象
![]()
+小tips
对于一些应用内存已经占满了，jstack 和 jmap 可能会连不上的情况，可以使用-F参数强制打印线程或者 dump 文件，但是要注意这两者使用的用户必须与 java 进程启动用户一致，并且使用的 jdk 也要一致
]]>
- MQ
- RocketMQ
- 消息队列
- RocketMQ
- 中间件
- RocketMQ
+ Java
+ Thread dump
+ 问题排查
+ 工具
- MQ
- 消息队列
- RocketMQ
- 削峰填谷
- 中间件
- 源码解析
- Broker
+ Java
+ JPS
+ JStack
+ JMap
- 聊聊 Sharding-Jdbc 的简单使用
- /2021/12/12/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E7%9A%84%E7%AE%80%E5%8D%95%E4%BD%BF%E7%94%A8/
- 我们在日常工作中还是使用比较多的分库分表组件的，其中比较优秀的就有 Sharding-Jdbc，一开始由当当开源，后来捐献给了 Apache，说一下简单使用，因为原来经常的使用都是基于 xml 跟 properties 组合起来使用，这里主要试下用 Java Config 来配置
首先是通过 Spring Initializr 创建个带 jdbc 的 Spring Boot 项目，然后引入主要的依赖
-<dependency>
- <groupId>org.apache.shardingsphere</groupId>
- <artifactId>shardingsphere-jdbc-core</artifactId>
- <version>5.0.0-beta</version>
-</dependency>
-因为前面有聊过 Spring Boot 的自动加载，在这里 spring 就会自己去找 DataSource 的配置，所以要在入口把它干掉
-@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class})
-public class ShardingJdbcDemoApplication implements CommandLineRunner {
-然后因为想在入口跑代码，就实现了下 org.springframework.boot.CommandLineRunner 主要是后面的 Java Config 代码
-
-// 注意这里的注解，可以让 Spring 自动帮忙加载，也就是 Java Config 的核心
-@Configuration
-public class MysqlConfig {
-
- @Bean
- public DataSource dataSource() throws SQLException {
- // Configure actual data sources
- Map<String, DataSource> dataSourceMap = new HashMap<>();
-
-
- // Configure the first data source
- // 使用了默认的Hikari连接池的 DataSource
- HikariDataSource dataSource1 = new HikariDataSource();
- dataSource1.setDriverClassName("com.mysql.jdbc.Driver");
- dataSource1.setJdbcUrl("jdbc:mysql://localhost:3306/sharding");
- dataSource1.setUsername("username");
- dataSource1.setPassword("password");
- dataSourceMap.put("ds0", dataSource1);
-
- // Configure student table rule
- // 这里是配置分表逻辑，逻辑表是 student，对应真实的表是 student_0 到 student_1, 这个配置方式就是有多少表可以用 student_$->{0..n}
- ShardingTableRuleConfiguration studentTableRuleConfig = new ShardingTableRuleConfiguration("student", "ds0.student_$->{0..1}");
-
- // 设置分表字段
- studentTableRuleConfig.setTableShardingStrategy(new StandardShardingStrategyConfiguration("user_id", "tableShardingAlgorithm"));
-
-
- // Configure sharding rule
- // 配置 studentTableRuleConfig
- ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();
- shardingRuleConfig.getTables().add(studentTableRuleConfig);
+ 聊聊 Linux 下的 top 命令
+ /2021/03/28/%E8%81%8A%E8%81%8A-Linux-%E4%B8%8B%E7%9A%84-top-%E5%91%BD%E4%BB%A4/
+ 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
- // Configure table sharding algorithm
- Properties tableShardingAlgorithmrProps = new Properties();
- // 算法表达式就是根据 user_id 对 2 进行取模
- tableShardingAlgorithmrProps.setProperty("algorithm-expression", "student_${user_id % 2}");
- shardingRuleConfig.getShardingAlgorithms().put("tableShardingAlgorithm", new ShardingSphereAlgorithmConfiguration("INLINE", tableShardingAlgorithmrProps));
+ For compatibility, this top supports most of the former top sort keys. Since this is primarily a service to former top users, these commands
+ do not appear on any help screen.
+ command sorted-field supported
+ A start time (non-display) No
+ M %MEM Yes
+ N PID Yes
+ P %CPU Yes
+ T TIME+ Yes
+ Before using any of the following sort provisions, top suggests that you temporarily turn on column highlighting using the `x' interactive com‐
+ mand. That will help ensure that the actual sort environment matches your intent.
- // 然后创建这个 DataSource
- return ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, Collections.singleton(shardingRuleConfig), new Properties());
+ The following interactive commands will only be honored when the current sort field is visible. The sort field might not be visible because:
+ 1) there is insufficient Screen Width
+ 2) the `f' interactive command turned it Off
- }
-}
-然后我们就可以在使用这个 DataSource 了，先看下这两个表的数据
![]()
![]()
-@Override
- public void run(String... args) {
- LOGGER.info("run here");
- String sql = "SELECT * FROM student WHERE user_id=? ";
- try (
- Connection conn = dataSource.getConnection();
- PreparedStatement ps = conn.prepareStatement(sql)) {
- // 参数就是 user_id，然后也是分表键，对 2 取模就是 1，应该是去 student_1 取数据
- ps.setInt(1, 1001);
+ < :Move-Sort-Field-Left
+ Moves the sort column to the left unless the current sort field is the first field being displayed.
- ResultSet resultSet = ps.executeQuery();
- while (resultSet.next()) {
- final int id = resultSet.getInt("id");
- final String name = resultSet.getString("name");
- final int userId = resultSet.getInt("user_id");
- final int age = resultSet.getInt("age");
- System.out.println("奇数表 id：" + id + " 姓名：" + name
- + " 用户 id：" + userId + " 年龄：" + age );
- System.out.println("=============================");
- }
- // 参数就是 user_id，然后也是分表键，对 2 取模就是 0，应该是去 student_0 取数据
- ps.setInt(1, 1000);
- resultSet = ps.executeQuery();
- while (resultSet.next()) {
- final int id = resultSet.getInt("id");
- final String name = resultSet.getString("name");
- final int userId = resultSet.getInt("user_id");
- final int age = resultSet.getInt("age");
- System.out.println("偶数表 id：" + id + " 姓名：" + name
- + " 用户 id：" + userId + " 年龄：" + age );
- System.out.println("=============================");
- }
- } catch (SQLException e) {
- e.printStackTrace();
- }
- }
-看下查询结果
![]()
-]]>
-
- Java
-
-
- Java
- Sharding-Jdbc
-
-
-
- 聊聊 dubbo 的线程池
- /2021/04/04/%E8%81%8A%E8%81%8A-dubbo-%E7%9A%84%E7%BA%BF%E7%A8%8B%E6%B1%A0/
- 之前没注意到这一块，只是比较模糊的印象 dubbo 自己基于 ThreadPoolExecutor 定义了几个线程池，但是没具体看过，主要是觉得就是为了避免使用 jdk 自带的那几个(java.util.concurrent.Executors)，防止出现那些问题
看下代码目录主要是这几个
![]()
-
-- FixedThreadPool：创建一个复用固定个数线程的线程池。
简单看下代码public Executor getExecutor(URL url) {
- String name = url.getParameter("threadname", "Dubbo");
- int threads = url.getParameter("threads", 200);
- int queues = url.getParameter("queues", 0);
- return new ThreadPoolExecutor(threads, threads, 0L, TimeUnit.MILLISECONDS, (BlockingQueue)(queues == 0 ? new SynchronousQueue() : (queues < 0 ? new LinkedBlockingQueue() : new LinkedBlockingQueue(queues))), new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
- }
-可以看到核心线程数跟最大线程数一致，也就是说就不会在核心线程数和最大线程数之间动态变化了
-- LimitedThreadPool：创建一个线程池，这个线程池中线程个数随着需要量动态增加，但是数量不超过配置的阈值的个数，另外空闲线程不会被回收，会一直存在。
public Executor getExecutor(URL url) {
- String name = url.getParameter("threadname", "Dubbo");
- int cores = url.getParameter("corethreads", 0);
- int threads = url.getParameter("threads", 200);
- int queues = url.getParameter("queues", 0);
- return new ThreadPoolExecutor(cores, threads, 9223372036854775807L, TimeUnit.MILLISECONDS, (BlockingQueue)(queues == 0 ? new SynchronousQueue() : (queues < 0 ? new LinkedBlockingQueue() : new LinkedBlockingQueue(queues))), new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
- }
-这个特点主要是创建了保活时间特别长，即可以认为不会被回收了
-- EagerThreadPool ：创建一个线程池，这个线程池当所有核心线程都处于忙碌状态时候，创建新的线程来执行新任务，而不是把任务放入线程池阻塞队列。
public Executor getExecutor(URL url) {
- String name = url.getParameter("threadname", "Dubbo");
- int cores = url.getParameter("corethreads", 0);
- int threads = url.getParameter("threads", 2147483647);
- int queues = url.getParameter("queues", 0);
- int alive = url.getParameter("alive", 60000);
- TaskQueue<Runnable> taskQueue = new TaskQueue(queues <= 0 ? 1 : queues);
- EagerThreadPoolExecutor executor = new EagerThreadPoolExecutor(cores, threads, (long)alive, TimeUnit.MILLISECONDS, taskQueue, new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
- taskQueue.setExecutor(executor);
- return executor;
- }
-这个是改动最多的一个了，因为需要实现这个机制，有兴趣的可以详细看下
-- CachedThreadPool： 创建一个自适应线程池，当线程处于空闲1分钟时候，线程会被回收，当有新请求到来时候会创建新线程
public Executor getExecutor(URL url) {
- String name = url.getParameter("threadname", "Dubbo");
- int cores = url.getParameter("corethreads", 0);
- int threads = url.getParameter("threads", 2147483647);
- 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，保活时间是一分钟
只是非常简略的介绍下，有兴趣可以自行阅读代码。
-
+ > :Move-Sort-Field-Right
+ Moves the sort column to the right unless the current sort field is the last field being displayed.
+查看 man page 可以找到这一段，其实一般 man page 都是最细致的，只不过因为太多了，有时候懒得看，这里可以通过大写 M 和大写 P 分别按内存和 CPU 排序，下面还有两个小技巧，通过按 x 可以将当前活跃的排序列用不同颜色标出来，然后可以通过<和>直接左右移动排序列
]]>
- Java
- Dubbo - 线程池
- Dubbo
- 线程池
- ThreadPool
+ Linux
+ 命令
+ 小技巧
+ top
+ top
+ 排序
- Java
- Dubbo
- ThreadPool
- 线程池
- FixedThreadPool
- LimitedThreadPool
- EagerThreadPool
- CachedThreadPool
+ 排序
+ linux
+ 小技巧
+ top
- 聊聊 Java 自带的那些*逆天*工具
- /2020/08/02/%E8%81%8A%E8%81%8A-Java-%E8%87%AA%E5%B8%A6%E7%9A%84%E9%82%A3%E4%BA%9B%E9%80%86%E5%A4%A9%E5%B7%A5%E5%85%B7/
- 原谅我的标题党，其实这些工具的确很厉害，之前其实介绍过一点相关的，是从我一次问题排查的过程中用到的，但是最近又有碰到一次排查问题，发现其实用 idea 直接 dump thread 是不现实的，毕竟服务器环境的没法这么操作，那就得用 Java 的那些工具了
-jstack & jps
譬如 jstack，这个命令其实不能更简单了
看看 help 信息
![]()
用-l参数可以打出锁的额外信息，然后后面的 pid 就是进程 id 咯，机智的小伙伴会问了（就你这个小白才问这么蠢的问题🤦♂️），怎么看 Java 应用的进程呢
那就是 jps 了，命令也很简单，一般直接用 jps命令就好了，不过也可以 help 看一下
![]()
稍微解释下，-q是只显示进程 id，-m是输出给main 方法的参数，比如我在配置中加给参数
![]()
然后用 jps -m查看
![]()
-v加上小 v 的话就是打印 jvm 参数
![]()
还是有点东西，然后就继续介绍 jstack 了，然后我们看看 jstack 出来是啥，为了加点内容我加了个死锁
-public static void main(String[] args) throws InterruptedException {
- SpringApplication.run(ThreadDumpDemoApplication.class, args);
- ReentrantLock lock1 = new ReentrantLock();
- ReentrantLock lock2 = new ReentrantLock();
- Thread t1 = new Thread() {
- @Override
- public void run() {
- try {
- lock1.lock();
- TimeUnit.SECONDS.sleep(1);
- lock2.lock();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- };
- Thread t2 = new Thread() {
- @Override
- public void run() {
- try {
- lock2.lock();
- TimeUnit.SECONDS.sleep(1);
- lock1.lock();
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- }
- };
- t1.setName("mythread1");
- t2.setName("mythread2");
- t1.start();
- t2.start();
- Thread.sleep(10000);
- }
-然后看看出来时怎么样的
-2020-08-02 21:50:32
-Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.201-b09 mixed mode):
-
-"DestroyJavaVM" #147 prio=5 os_prio=31 tid=0x00007fc9dd807000 nid=0x2603 waiting on condition [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
-
- Locked ownable synchronizers:
- - None
+ 聊聊 RocketMQ 的 Broker 源码
+ /2020/07/19/%E8%81%8A%E8%81%8A-RocketMQ-%E7%9A%84-Broker-%E6%BA%90%E7%A0%81/
+ broker 的启动形式有点类似于 NameServer，都是服务类型的，跟 Consumer 差别比较大，
+首先是org.apache.rocketmq.broker.BrokerStartup中的 main 函数，org.apache.rocketmq.broker.BrokerStartup#createBrokerController基本就是读取参数，这里差点把最核心的初始化给漏了，
+final BrokerController controller = new BrokerController(
+ brokerConfig,
+ nettyServerConfig,
+ nettyClientConfig,
+ messageStoreConfig);
+ // remember all configs to prevent discard
+ controller.getConfiguration().registerConfig(properties);
-"mythread2" #140 prio=5 os_prio=31 tid=0x00007fc9dd877000 nid=0x9903 waiting on condition [0x0000700006fb9000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f5d4330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
- at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
- at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
- at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$2.run(ThreadDumpDemoApplication.java:34)
+ boolean initResult = controller.initialize();
- Locked ownable synchronizers:
- - <0x000000076f5d4360> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
+前面是以 broker 配置，netty 的服务端和客户端配置，以及消息存储配置在实例化 BrokerController，然后就是初始化了
+public boolean initialize() throws CloneNotSupportedException {
+ boolean result = this.topicConfigManager.load();
-"mythread1" #139 prio=5 os_prio=31 tid=0x00007fc9de873800 nid=0x9a03 waiting on condition [0x0000700006eb6000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f5d4360> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
- at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
- at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
- at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$1.run(ThreadDumpDemoApplication.java:22)
+ result = result && this.consumerOffsetManager.load();
+ result = result && this.subscriptionGroupManager.load();
+ result = result && this.consumerFilterManager.load();
- Locked ownable synchronizers:
- - <0x000000076f5d4330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
+前面这些就是各个配置的 load 了，然后是个我认为比较重要的部分messageStore 的实例化，
+if (result) {
+ try {
+ this.messageStore =
+ new DefaultMessageStore(this.messageStoreConfig, this.brokerStatsManager, this.messageArrivingListener,
+ this.brokerConfig);
+ if (messageStoreConfig.isEnableDLegerCommitLog()) {
+ DLedgerRoleChangeHandler roleChangeHandler = new DLedgerRoleChangeHandler(this, (DefaultMessageStore) messageStore);
+ ((DLedgerCommitLog)((DefaultMessageStore) messageStore).getCommitLog()).getdLedgerServer().getdLedgerLeaderElector().addRoleChangeHandler(roleChangeHandler);
+ }
+ this.brokerStats = new BrokerStats((DefaultMessageStore) this.messageStore);
+ //load plugin
+ MessageStorePluginContext context = new MessageStorePluginContext(messageStoreConfig, brokerStatsManager, messageArrivingListener, brokerConfig);
+ this.messageStore = MessageStoreFactory.build(context, this.messageStore);
+ this.messageStore.getDispatcherList().addFirst(new CommitLogDispatcherCalcBitMap(this.brokerConfig, this.consumerFilterManager));
+ } catch (IOException e) {
+ result = false;
+ log.error("Failed to initialize", e);
+ }
+}
-"http-nio-8080-Acceptor" #137 daemon prio=5 os_prio=31 tid=0x00007fc9de1ac000 nid=0x9b03 runnable [0x0000700006db3000]
- java.lang.Thread.State: RUNNABLE
- at sun.nio.ch.ServerSocketChannelImpl.accept0(Native Method)
- at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:422)
- at sun.nio.ch.ServerSocketChannelImpl.accept(ServerSocketChannelImpl.java:250)
- - locked <0x000000076f1e4820> (a java.lang.Object)
- at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:469)
- at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:71)
- at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:95)
- at java.lang.Thread.run(Thread.java:748)
+result = result && this.messageStore.load();
- Locked ownable synchronizers:
- - None
+先是实例化，实例化构造函数里的代码比较重要，重点看一下
+public DefaultMessageStore(final MessageStoreConfig messageStoreConfig, final BrokerStatsManager brokerStatsManager,
+ final MessageArrivingListener messageArrivingListener, final BrokerConfig brokerConfig) throws IOException {
+ this.messageArrivingListener = messageArrivingListener;
+ this.brokerConfig = brokerConfig;
+ this.messageStoreConfig = messageStoreConfig;
+ this.brokerStatsManager = brokerStatsManager;
+ this.allocateMappedFileService = new AllocateMappedFileService(this);
+ if (messageStoreConfig.isEnableDLegerCommitLog()) {
+ this.commitLog = new DLedgerCommitLog(this);
+ } else {
+ this.commitLog = new CommitLog(this);
+ }
+ this.consumeQueueTable = new ConcurrentHashMap<>(32);
-"http-nio-8080-ClientPoller" #136 daemon prio=5 os_prio=31 tid=0x00007fc9dd876800 nid=0x6503 runnable [0x0000700006cb0000]
- java.lang.Thread.State: RUNNABLE
- at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
- at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
- at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
- at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- - locked <0x000000076f2978c8> (a sun.nio.ch.Util$3)
- - locked <0x000000076f2978b8> (a java.util.Collections$UnmodifiableSet)
- - locked <0x000000076f297798> (a sun.nio.ch.KQueueSelectorImpl)
- at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
- at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:709)
- at java.lang.Thread.run(Thread.java:748)
+ this.flushConsumeQueueService = new FlushConsumeQueueService();
+ this.cleanCommitLogService = new CleanCommitLogService();
+ this.cleanConsumeQueueService = new CleanConsumeQueueService();
+ this.storeStatsService = new StoreStatsService();
+ this.indexService = new IndexService(this);
+ if (!messageStoreConfig.isEnableDLegerCommitLog()) {
+ this.haService = new HAService(this);
+ } else {
+ this.haService = null;
+ }
+ this.reputMessageService = new ReputMessageService();
- Locked ownable synchronizers:
- - None
+ this.scheduleMessageService = new ScheduleMessageService(this);
-"http-nio-8080-exec-10" #135 daemon prio=5 os_prio=31 tid=0x00007fc9de1af000 nid=0x9d03 waiting on condition [0x0000700006bad000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.transientStorePool = new TransientStorePool(messageStoreConfig);
- Locked ownable synchronizers:
- - None
+ if (messageStoreConfig.isTransientStorePoolEnable()) {
+ this.transientStorePool.init();
+ }
-"http-nio-8080-exec-9" #134 daemon prio=5 os_prio=31 tid=0x00007fc9de1ab800 nid=0x6403 waiting on condition [0x0000700006aaa000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.allocateMappedFileService.start();
- Locked ownable synchronizers:
- - None
+ this.indexService.start();
-"http-nio-8080-exec-8" #133 daemon prio=5 os_prio=31 tid=0x00007fc9de873000 nid=0x9f03 waiting on condition [0x00007000069a7000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.dispatcherList = new LinkedList<>();
+ this.dispatcherList.addLast(new CommitLogDispatcherBuildConsumeQueue());
+ this.dispatcherList.addLast(new CommitLogDispatcherBuildIndex());
- Locked ownable synchronizers:
- - None
+ File file = new File(StorePathConfigHelper.getLockFile(messageStoreConfig.getStorePathRootDir()));
+ MappedFile.ensureDirOK(file.getParent());
+ lockFile = new RandomAccessFile(file, "rw");
+ }
-"http-nio-8080-exec-7" #132 daemon prio=5 os_prio=31 tid=0x00007fc9df0a1800 nid=0xa103 waiting on condition [0x00007000068a4000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+这里面有很多类，不过先把从构造函数里传进来的忽略下，接下来就是 AllocateMappedFileService 这个service，前面看过文章的可能会根据上面的代码猜到，这也是个 ServiceThread，如果是对RocketMQ 有所了解的可能从名字可以看出这个类是关于 RocketMQ 消息怎么落盘的，当需要创建MappedFile时（在MapedFileQueue.getLastMapedFile方法中），向该线程的requestQueue队列中放入AllocateRequest请求对象，该线程会在后台监听该队列，并在后台创建MapedFile对象，即同时创建了物理文件。然后是创建了 IndexService 服务线程，用来给创建索引；还有是FlushConsumeQueueService是将ConsumeQueue 刷入磁盘；CleanCommitLogService用来清理过期的 CommitLog，默认是 72 小时以上；CleanConsumeQueueService是将小于最新的 CommitLog 偏移量的 ConsumeQueue 清理掉；StoreStatsService是储存统计服务；HAService用于CommitLog 的主备同步；ScheduleMessageService用于定时消息；还有就是这个ReputMessageService非常重要，就是由它实现了将 CommitLog 以 topic+queue 纬度构建 ConsumeQueue，后面TransientStorePool是异步刷盘时的存储buffer，也可以从后面的判断中看出来
+public boolean isTransientStorePoolEnable() {
+ return transientStorePoolEnable && FlushDiskType.ASYNC_FLUSH == getFlushDiskType()
+ && BrokerRole.SLAVE != getBrokerRole();
+ }
- Locked ownable synchronizers:
- - None
+再然后就是启动两个服务线程，dispatcherList是为CommitLog文件转发请求，差不多这个初始化就这些内容。
+然后回到外层，下面是主备切换的配置，然后是数据统计，接着是存储插件加载，然后是往转发器链表里再加一个过滤器
+if (messageStoreConfig.isEnableDLegerCommitLog()) {
+ DLedgerRoleChangeHandler roleChangeHandler = new DLedgerRoleChangeHandler(this, (DefaultMessageStore) messageStore);
+ ((DLedgerCommitLog)((DefaultMessageStore) messageStore).getCommitLog()).getdLedgerServer().getdLedgerLeaderElector().addRoleChangeHandler(roleChangeHandler);
+ }
+ this.brokerStats = new BrokerStats((DefaultMessageStore) this.messageStore);
+ //load plugin
+ MessageStorePluginContext context = new MessageStorePluginContext(messageStoreConfig, brokerStatsManager, messageArrivingListener, brokerConfig);
+ this.messageStore = MessageStoreFactory.build(context, this.messageStore);
+ this.messageStore.getDispatcherList().addFirst(new CommitLogDispatcherCalcBitMap(this.brokerConfig, this.consumerFilterManager));
-"http-nio-8080-exec-6" #131 daemon prio=5 os_prio=31 tid=0x00007fc9df242800 nid=0x6103 waiting on condition [0x00007000067a1000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+接下来就是org.apache.rocketmq.store.MessageStore#load的过程了，
+
+- 调用ScheduleMessageService.load方法，初始化延迟级别列表。将这些级别（”1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”）的延时存入延迟级别delayLevelTable：ConcurrentHashMap<Integer /* level */, Long/* delay timeMillis */>变量中，例如1s的kv值为1:1000,5s的kv值为2:5000，key值依次类推；每个延迟级别即为一个队列。
+
+2)调用CommitLog.load方法，在此方法中调用MapedFileQueue.load方法，将$HOME /store/commitlog目录下的所有文件加载到MapedFileQueue的List变量中；
+3)调用DefaultMessageStore.loadConsumeQueue方法加载consumequeue文件数据到DefaultMessageStore.consumeQueueTable集合中。
+初始化StoreCheckPoint对象，加载$HOME/store/checkpoint文件，该文件记录三个字段值，分别是物理队列消息时间戳、逻辑队列消息时间戳、索引队列消息时间戳。
+调用IndexService.load方法加载$HOME/store/index目录下的文件。对该目录下的每个文件初始化一个IndexFile对象。然后调用IndexFile对象的load方法将IndexHeader加载到对象的变量中；再根据检查是否存在abort文件，若有存在abort文件，则表示Broker表示上次是异常退出的，则检查checkpoint的indexMsgTimestamp字段值是否小于IndexHeader的endTimestamp值，indexMsgTimestamp值表示最后刷盘的时间，若小于则表示在最后刷盘之后在该文件中还创建了索引，则要删除该Index文件，否则将该IndexFile对象放入indexFileList:ArrayList索引文件集合中。
+然后调用org.apache.rocketmq.store.DefaultMessageStore#recover恢复，前面有根据boolean lastExitOK = !this.isTempFileExist();临时文件是否存在来判断上一次是否正常退出，根据这个状态来选择什么恢复策略
+接下去是初始化 Netty 服务端，初始化发送消息线程池（sendMessageExecutor）、拉取消息线程池（pullMessageExecutor）、管理Broker线程池（adminBrokerExecutor）、客户端管理线程池（clientManageExecutor），注册事件处理器，包括发送消息事件处理器（SendMessageProcessor）、拉取消息事件处理器、查询消息事件处理器（QueryMessageProcessor，包括客户端的心跳事件、注销事件、获取消费者列表事件、更新更新和查询消费进度consumerOffset）、客户端管理事件处理器（ClientManageProcessor）、结束事务处理器（EndTransactionProcessor）、默认事件处理器（AdminBrokerProcessor），然后是定时任务
+BrokerController.this.getBrokerStats().record(); 记录 Broker 状态
+BrokerController.this.consumerOffsetManager.persist(); 持久化consumerOffset
+BrokerController.this.consumerFilterManager.persist();持久化consumerFilter
+BrokerController.this.protectBroker(); 保护 broker，消费慢，不让继续投递
+BrokerController.this.printWaterMark(); 打印水位
+log.info("dispatch behind commit log {} bytes", BrokerController.this.getMessageStore().dispatchBehindBytes()); 检查落后程度
+BrokerController.this.brokerOuterAPI.fetchNameServerAddr(); 定时获取 nameserver
+BrokerController.this.printMasterAndSlaveDiff(); 打印主从不一致
+然后是 tsl，初始化事务消息，初始化 RPCHook
+请把害怕打到公屏上🤦♂️，从线程池名字和调用的方法应该可以看出大部分的用途
+this.remotingServer = new NettyRemotingServer(this.nettyServerConfig, this.clientHousekeepingService);
+ NettyServerConfig fastConfig = (NettyServerConfig) this.nettyServerConfig.clone();
+ fastConfig.setListenPort(nettyServerConfig.getListenPort() - 2);
+ this.fastRemotingServer = new NettyRemotingServer(fastConfig, this.clientHousekeepingService);
+ this.sendMessageExecutor = new BrokerFixedThreadPoolExecutor(
+ this.brokerConfig.getSendMessageThreadPoolNums(),
+ this.brokerConfig.getSendMessageThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.sendThreadPoolQueue,
+ new ThreadFactoryImpl("SendMessageThread_"));
- Locked ownable synchronizers:
- - None
+ this.pullMessageExecutor = new BrokerFixedThreadPoolExecutor(
+ this.brokerConfig.getPullMessageThreadPoolNums(),
+ this.brokerConfig.getPullMessageThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.pullThreadPoolQueue,
+ new ThreadFactoryImpl("PullMessageThread_"));
-"http-nio-8080-exec-5" #130 daemon prio=5 os_prio=31 tid=0x00007fc9de872000 nid=0x5f03 waiting on condition [0x000070000669e000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.replyMessageExecutor = new BrokerFixedThreadPoolExecutor(
+ this.brokerConfig.getProcessReplyMessageThreadPoolNums(),
+ this.brokerConfig.getProcessReplyMessageThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.replyThreadPoolQueue,
+ new ThreadFactoryImpl("ProcessReplyMessageThread_"));
- Locked ownable synchronizers:
- - None
+ this.queryMessageExecutor = new BrokerFixedThreadPoolExecutor(
+ this.brokerConfig.getQueryMessageThreadPoolNums(),
+ this.brokerConfig.getQueryMessageThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.queryThreadPoolQueue,
+ new ThreadFactoryImpl("QueryMessageThread_"));
-"http-nio-8080-exec-4" #129 daemon prio=5 os_prio=31 tid=0x00007fc9de1a6000 nid=0x5e03 waiting on condition [0x000070000659b000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.adminBrokerExecutor =
+ Executors.newFixedThreadPool(this.brokerConfig.getAdminBrokerThreadPoolNums(), new ThreadFactoryImpl(
+ "AdminBrokerThread_"));
- Locked ownable synchronizers:
- - None
+ this.clientManageExecutor = new ThreadPoolExecutor(
+ this.brokerConfig.getClientManageThreadPoolNums(),
+ this.brokerConfig.getClientManageThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.clientManagerThreadPoolQueue,
+ new ThreadFactoryImpl("ClientManageThread_"));
-"http-nio-8080-exec-3" #128 daemon prio=5 os_prio=31 tid=0x00007fc9de871800 nid=0x5c03 waiting on condition [0x0000700006498000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.heartbeatExecutor = new BrokerFixedThreadPoolExecutor(
+ this.brokerConfig.getHeartbeatThreadPoolNums(),
+ this.brokerConfig.getHeartbeatThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.heartbeatThreadPoolQueue,
+ new ThreadFactoryImpl("HeartbeatThread_", true));
- Locked ownable synchronizers:
- - None
+ this.endTransactionExecutor = new BrokerFixedThreadPoolExecutor(
+ this.brokerConfig.getEndTransactionThreadPoolNums(),
+ this.brokerConfig.getEndTransactionThreadPoolNums(),
+ 1000 * 60,
+ TimeUnit.MILLISECONDS,
+ this.endTransactionThreadPoolQueue,
+ new ThreadFactoryImpl("EndTransactionThread_"));
-"http-nio-8080-exec-2" #127 daemon prio=5 os_prio=31 tid=0x00007fc9dead9000 nid=0x5b03 waiting on condition [0x0000700006395000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ this.consumerManageExecutor =
+ Executors.newFixedThreadPool(this.brokerConfig.getConsumerManageThreadPoolNums(), new ThreadFactoryImpl(
+ "ConsumerManageThread_"));
- Locked ownable synchronizers:
- - None
+ this.registerProcessor();
-"http-nio-8080-exec-1" #126 daemon prio=5 os_prio=31 tid=0x00007fc9ddb00000 nid=0x5a03 waiting on condition [0x0000700006292000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f26aa00> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:107)
- at org.apache.tomcat.util.threads.TaskQueue.take(TaskQueue.java:33)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ final long initialDelay = UtilAll.computeNextMorningTimeMillis() - System.currentTimeMillis();
+ final long period = 1000 * 60 * 60 * 24;
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.getBrokerStats().record();
+ } catch (Throwable e) {
+ log.error("schedule record error.", e);
+ }
+ }
+ }, initialDelay, period, TimeUnit.MILLISECONDS);
- Locked ownable synchronizers:
- - None
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.consumerOffsetManager.persist();
+ } catch (Throwable e) {
+ log.error("schedule persist consumerOffset error.", e);
+ }
+ }
+ }, 1000 * 10, this.brokerConfig.getFlushConsumerOffsetInterval(), TimeUnit.MILLISECONDS);
-"http-nio-8080-BlockPoller" #125 daemon prio=5 os_prio=31 tid=0x00007fc9df242000 nid=0xa503 runnable [0x000070000618f000]
- java.lang.Thread.State: RUNNABLE
- at sun.nio.ch.KQueueArrayWrapper.kevent0(Native Method)
- at sun.nio.ch.KQueueArrayWrapper.poll(KQueueArrayWrapper.java:198)
- at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:117)
- at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
- - locked <0x000000076f1eea30> (a sun.nio.ch.Util$3)
- - locked <0x000000076f1ee198> (a java.util.Collections$UnmodifiableSet)
- - locked <0x000000076f1ee010> (a sun.nio.ch.KQueueSelectorImpl)
- at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
- at org.apache.tomcat.util.net.NioBlockingSelector$BlockPoller.run(NioBlockingSelector.java:313)
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.consumerFilterManager.persist();
+ } catch (Throwable e) {
+ log.error("schedule persist consumer filter error.", e);
+ }
+ }
+ }, 1000 * 10, 1000 * 10, TimeUnit.MILLISECONDS);
- Locked ownable synchronizers:
- - None
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.protectBroker();
+ } catch (Throwable e) {
+ log.error("protectBroker error.", e);
+ }
+ }
+ }, 3, 3, TimeUnit.MINUTES);
-"container-0" #124 prio=5 os_prio=31 tid=0x00007fc9df06a000 nid=0x5803 waiting on condition [0x000070000608c000]
- java.lang.Thread.State: TIMED_WAITING (sleeping)
- at java.lang.Thread.sleep(Native Method)
- at org.apache.catalina.core.StandardServer.await(StandardServer.java:570)
- at org.springframework.boot.web.embedded.tomcat.TomcatWebServer$1.run(TomcatWebServer.java:197)
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.printWaterMark();
+ } catch (Throwable e) {
+ log.error("printWaterMark error.", e);
+ }
+ }
+ }, 10, 1, TimeUnit.SECONDS);
- Locked ownable synchronizers:
- - None
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
-"Catalina-utility-2" #123 prio=1 os_prio=31 tid=0x00007fc9de886000 nid=0xa80f waiting on condition [0x0000700005f89000]
- java.lang.Thread.State: WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076c88ab58> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
- at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1088)
- at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
-
- Locked ownable synchronizers:
- - None
+ @Override
+ public void run() {
+ try {
+ log.info("dispatch behind commit log {} bytes", BrokerController.this.getMessageStore().dispatchBehindBytes());
+ } catch (Throwable e) {
+ log.error("schedule dispatchBehindBytes error.", e);
+ }
+ }
+ }, 1000 * 10, 1000 * 60, TimeUnit.MILLISECONDS);
-"Catalina-utility-1" #122 prio=1 os_prio=31 tid=0x00007fc9de884000 nid=0x5667 waiting on condition [0x0000700005e86000]
- java.lang.Thread.State: TIMED_WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076c88ab58> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
- at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
- at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
- at java.lang.Thread.run(Thread.java:748)
+ if (this.brokerConfig.getNamesrvAddr() != null) {
+ this.brokerOuterAPI.updateNameServerAddressList(this.brokerConfig.getNamesrvAddr());
+ log.info("Set user specified name server address: {}", this.brokerConfig.getNamesrvAddr());
+ } else if (this.brokerConfig.isFetchNamesrvAddrByAddressServer()) {
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
- Locked ownable synchronizers:
- - None
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.brokerOuterAPI.fetchNameServerAddr();
+ } catch (Throwable e) {
+ log.error("ScheduledTask fetchNameServerAddr exception", e);
+ }
+ }
+ }, 1000 * 10, 1000 * 60 * 2, TimeUnit.MILLISECONDS);
+ }
-"RMI Scheduler(0)" #15 daemon prio=5 os_prio=31 tid=0x00007fc9de9ee000 nid=0x5503 waiting on condition [0x0000700005d83000]
- java.lang.Thread.State: TIMED_WAITING (parking)
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x00000006c0015410> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
- at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2078)
- at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1093)
- at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:809)
- at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
- at java.lang.Thread.run(Thread.java:748)
+ if (!messageStoreConfig.isEnableDLegerCommitLog()) {
+ if (BrokerRole.SLAVE == this.messageStoreConfig.getBrokerRole()) {
+ if (this.messageStoreConfig.getHaMasterAddress() != null && this.messageStoreConfig.getHaMasterAddress().length() >= 6) {
+ this.messageStore.updateHaMasterAddress(this.messageStoreConfig.getHaMasterAddress());
+ this.updateMasterHAServerAddrPeriodically = false;
+ } else {
+ this.updateMasterHAServerAddrPeriodically = true;
+ }
+ } else {
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.printMasterAndSlaveDiff();
+ } catch (Throwable e) {
+ log.error("schedule printMasterAndSlaveDiff error.", e);
+ }
+ }
+ }, 1000 * 10, 1000 * 60, TimeUnit.MILLISECONDS);
+ }
+ }
- Locked ownable synchronizers:
- - None
+ if (TlsSystemConfig.tlsMode != TlsMode.DISABLED) {
+ // Register a listener to reload SslContext
+ try {
+ fileWatchService = new FileWatchService(
+ new String[] {
+ TlsSystemConfig.tlsServerCertPath,
+ TlsSystemConfig.tlsServerKeyPath,
+ TlsSystemConfig.tlsServerTrustCertPath
+ },
+ new FileWatchService.Listener() {
+ boolean certChanged, keyChanged = false;
-"Attach Listener" #13 daemon prio=9 os_prio=31 tid=0x00007fc9df149800 nid=0x3c07 waiting on condition [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
+ @Override
+ public void onChanged(String path) {
+ if (path.equals(TlsSystemConfig.tlsServerTrustCertPath)) {
+ log.info("The trust certificate changed, reload the ssl context");
+ reloadServerSslContext();
+ }
+ if (path.equals(TlsSystemConfig.tlsServerCertPath)) {
+ certChanged = true;
+ }
+ if (path.equals(TlsSystemConfig.tlsServerKeyPath)) {
+ keyChanged = true;
+ }
+ if (certChanged && keyChanged) {
+ log.info("The certificate and private key changed, reload the ssl context");
+ certChanged = keyChanged = false;
+ reloadServerSslContext();
+ }
+ }
- Locked ownable synchronizers:
- - None
+ private void reloadServerSslContext() {
+ ((NettyRemotingServer) remotingServer).loadSslContext();
+ ((NettyRemotingServer) fastRemotingServer).loadSslContext();
+ }
+ });
+ } catch (Exception e) {
+ log.warn("FileWatchService created error, can't load the certificate dynamically");
+ }
+ }
+ initialTransaction();
+ initialAcl();
+ initialRpcHooks();
+ }
+ return result;
-"RMI TCP Accept-0" #11 daemon prio=5 os_prio=31 tid=0x00007fc9df100000 nid=0x4003 runnable [0x0000700005977000]
- java.lang.Thread.State: RUNNABLE
- at java.net.PlainSocketImpl.socketAccept(Native Method)
- at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
- at java.net.ServerSocket.implAccept(ServerSocket.java:545)
- at java.net.ServerSocket.accept(ServerSocket.java:513)
- at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)
- at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:405)
- at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:377)
- at java.lang.Thread.run(Thread.java:748)
- Locked ownable synchronizers:
- - None
-"Service Thread" #9 daemon prio=9 os_prio=31 tid=0x00007fc9df0ce800 nid=0x4103 runnable [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
+Broker 启动过程
+贴代码
+public void start() throws Exception {
+ if (this.messageStore != null) {
+ this.messageStore.start();
+ }
- Locked ownable synchronizers:
- - None
+ if (this.remotingServer != null) {
+ this.remotingServer.start();
+ }
-"C1 CompilerThread2" #8 daemon prio=9 os_prio=31 tid=0x00007fc9df0ce000 nid=0x4203 waiting on condition [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
+ if (this.fastRemotingServer != null) {
+ this.fastRemotingServer.start();
+ }
- Locked ownable synchronizers:
- - None
+ if (this.fileWatchService != null) {
+ this.fileWatchService.start();
+ }
-"C2 CompilerThread1" #7 daemon prio=9 os_prio=31 tid=0x00007fc9de0a3800 nid=0x3503 waiting on condition [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
+ if (this.brokerOuterAPI != null) {
+ this.brokerOuterAPI.start();
+ }
- Locked ownable synchronizers:
- - None
+ if (this.pullRequestHoldService != null) {
+ this.pullRequestHoldService.start();
+ }
-"C2 CompilerThread0" #6 daemon prio=9 os_prio=31 tid=0x00007fc9de89b000 nid=0x3403 waiting on condition [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
+ if (this.clientHousekeepingService != null) {
+ this.clientHousekeepingService.start();
+ }
- Locked ownable synchronizers:
- - None
+ if (this.filterServerManager != null) {
+ this.filterServerManager.start();
+ }
-"Monitor Ctrl-Break" #5 daemon prio=5 os_prio=31 tid=0x00007fc9df0ca000 nid=0x3303 runnable [0x0000700005468000]
- java.lang.Thread.State: RUNNABLE
- at java.net.SocketInputStream.socketRead0(Native Method)
- at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
- at java.net.SocketInputStream.read(SocketInputStream.java:171)
- at java.net.SocketInputStream.read(SocketInputStream.java:141)
- at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
- at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
- at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
- - locked <0x00000006c001b760> (a java.io.InputStreamReader)
- at java.io.InputStreamReader.read(InputStreamReader.java:184)
- at java.io.BufferedReader.fill(BufferedReader.java:161)
- at java.io.BufferedReader.readLine(BufferedReader.java:324)
- - locked <0x00000006c001b760> (a java.io.InputStreamReader)
- at java.io.BufferedReader.readLine(BufferedReader.java:389)
- at com.intellij.rt.execution.application.AppMainV2$1.run(AppMainV2.java:64)
+ if (!messageStoreConfig.isEnableDLegerCommitLog()) {
+ startProcessorByHa(messageStoreConfig.getBrokerRole());
+ handleSlaveSynchronize(messageStoreConfig.getBrokerRole());
+ this.registerBrokerAll(true, false, true);
+ }
- Locked ownable synchronizers:
- - None
+ this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
-"Signal Dispatcher" #4 daemon prio=9 os_prio=31 tid=0x00007fc9de824000 nid=0x4503 runnable [0x0000000000000000]
- java.lang.Thread.State: RUNNABLE
+ @Override
+ public void run() {
+ try {
+ BrokerController.this.registerBrokerAll(true, false, brokerConfig.isForceRegister());
+ } catch (Throwable e) {
+ log.error("registerBrokerAll Exception", e);
+ }
+ }
+ }, 1000 * 10, Math.max(10000, Math.min(brokerConfig.getRegisterNameServerPeriod(), 60000)), TimeUnit.MILLISECONDS);
- Locked ownable synchronizers:
- - None
+ if (this.brokerStatsManager != null) {
+ this.brokerStatsManager.start();
+ }
-"Finalizer" #3 daemon prio=8 os_prio=31 tid=0x00007fc9dd811800 nid=0x4f03 in Object.wait() [0x0000700005262000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x00000006c0008348> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:144)
- - locked <0x00000006c0008348> (a java.lang.ref.ReferenceQueue$Lock)
- at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:165)
- at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:216)
+ if (this.brokerFastFailure != null) {
+ this.brokerFastFailure.start();
+ }
- Locked ownable synchronizers:
- - None
-"Reference Handler" #2 daemon prio=10 os_prio=31 tid=0x00007fc9de02a000 nid=0x5003 in Object.wait() [0x000070000515f000]
- java.lang.Thread.State: WAITING (on object monitor)
- at java.lang.Object.wait(Native Method)
- - waiting on <0x00000006c001b940> (a java.lang.ref.Reference$Lock)
- at java.lang.Object.wait(Object.java:502)
- at java.lang.ref.Reference.tryHandlePending(Reference.java:191)
- - locked <0x00000006c001b940> (a java.lang.ref.Reference$Lock)
- at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:153)
+ }
- Locked ownable synchronizers:
- - None
+首先是启动messageStore，调用 start 方法，这里面又调用了一些代码
+public void start() throws Exception {
-"VM Thread" os_prio=31 tid=0x00007fc9df00b800 nid=0x2c03 runnable
+ lock = lockFile.getChannel().tryLock(0, 1, false);
+ if (lock == null || lock.isShared() || !lock.isValid()) {
+ throw new RuntimeException("Lock failed,MQ already started");
+ }
-"GC task thread#0 (ParallelGC)" os_prio=31 tid=0x00007fc9de805000 nid=0x1e07 runnable
-
-"GC task thread#1 (ParallelGC)" os_prio=31 tid=0x00007fc9de003800 nid=0x2a03 runnable
-
-"GC task thread#2 (ParallelGC)" os_prio=31 tid=0x00007fc9df002000 nid=0x5403 runnable
-
-"GC task thread#3 (ParallelGC)" os_prio=31 tid=0x00007fc9df002800 nid=0x5203 runnable
-
-"VM Periodic Task Thread" os_prio=31 tid=0x00007fc9df11a800 nid=0x3a03 waiting on condition
-
-JNI global references: 1087
+ lockFile.getChannel().write(ByteBuffer.wrap("lock".getBytes()));
+ lockFile.getChannel().force(true);
+ {
+ /**
+ * 1. Make sure the fast-forward messages to be truncated during the recovering according to the max physical offset of the commitlog;
+ * 2. DLedger committedPos may be missing, so the maxPhysicalPosInLogicQueue maybe bigger that maxOffset returned by DLedgerCommitLog, just let it go;
+ * 3. Calculate the reput offset according to the consume queue;
+ * 4. Make sure the fall-behind messages to be dispatched before starting the commitlog, especially when the broker role are automatically changed.
+ */
+ long maxPhysicalPosInLogicQueue = commitLog.getMinOffset();
+ for (ConcurrentMap<Integer, ConsumeQueue> maps : this.consumeQueueTable.values()) {
+ for (ConsumeQueue logic : maps.values()) {
+ if (logic.getMaxPhysicOffset() > maxPhysicalPosInLogicQueue) {
+ maxPhysicalPosInLogicQueue = logic.getMaxPhysicOffset();
+ }
+ }
+ }
+ if (maxPhysicalPosInLogicQueue < 0) {
+ maxPhysicalPosInLogicQueue = 0;
+ }
+ if (maxPhysicalPosInLogicQueue < this.commitLog.getMinOffset()) {
+ maxPhysicalPosInLogicQueue = this.commitLog.getMinOffset();
+ /**
+ * This happens in following conditions:
+ * 1. If someone removes all the consumequeue files or the disk get damaged.
+ * 2. Launch a new broker, and copy the commitlog from other brokers.
+ *
+ * All the conditions has the same in common that the maxPhysicalPosInLogicQueue should be 0.
+ * If the maxPhysicalPosInLogicQueue is gt 0, there maybe something wrong.
+ */
+ log.warn("[TooSmallCqOffset] maxPhysicalPosInLogicQueue={} clMinOffset={}", maxPhysicalPosInLogicQueue, this.commitLog.getMinOffset());
+ }
+ log.info("[SetReputOffset] maxPhysicalPosInLogicQueue={} clMinOffset={} clMaxOffset={} clConfirmedOffset={}",
+ maxPhysicalPosInLogicQueue, this.commitLog.getMinOffset(), this.commitLog.getMaxOffset(), this.commitLog.getConfirmOffset());
+ this.reputMessageService.setReputFromOffset(maxPhysicalPosInLogicQueue);
+ this.reputMessageService.start();
+ /**
+ * 1. Finish dispatching the messages fall behind, then to start other services.
+ * 2. DLedger committedPos may be missing, so here just require dispatchBehindBytes <= 0
+ */
+ while (true) {
+ if (dispatchBehindBytes() <= 0) {
+ break;
+ }
+ Thread.sleep(1000);
+ log.info("Try to finish doing reput the messages fall behind during the starting, reputOffset={} maxOffset={} behind={}", this.reputMessageService.getReputFromOffset(), this.getMaxPhyOffset(), this.dispatchBehindBytes());
+ }
+ this.recoverTopicQueueTable();
+ }
-Found one Java-level deadlock:
-=============================
-"mythread2":
- waiting for ownable synchronizer 0x000000076f5d4330, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
- which is held by "mythread1"
-"mythread1":
- waiting for ownable synchronizer 0x000000076f5d4360, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
- which is held by "mythread2"
+ if (!messageStoreConfig.isEnableDLegerCommitLog()) {
+ this.haService.start();
+ this.handleScheduleMessageService(messageStoreConfig.getBrokerRole());
+ }
-Java stack information for the threads listed above:
-===================================================
-"mythread2":
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f5d4330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
- at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
- at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
- at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$2.run(ThreadDumpDemoApplication.java:34)
-"mythread1":
- at sun.misc.Unsafe.park(Native Method)
- - parking to wait for <0x000000076f5d4360> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
- at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
- at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
- at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
- at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
- at com.nicksxs.thread_dump_demo.ThreadDumpDemoApplication$1.run(ThreadDumpDemoApplication.java:22)
+ this.flushConsumeQueueService.start();
+ this.commitLog.start();
+ this.storeStatsService.start();
-Found 1 deadlock.
-前面的信息其实上次就看过了，后面就可以发现有个死锁了，
![]()
上面比较长，把主要的截出来，就是这边的，这点就很强大了。
-jmap
惯例还是看一下帮助信息
![]()
这个相对命令比较多，不过因为现在 dump 下来我们可能会用文件模式，然后将文件下载下来使用 mat 进行分析，所以可以使用
jmap -dump:live,format=b,file=heap.bin <pid>
命令照着上面看的就是打印活着的对象，然后以二进制格式，文件名叫 heap.bin 然后最后就是进程 id，打印出来以后可以用 mat 打开
![]()
这样就可以很清晰的看到应用里的各种信息，jmap 直接在命令中还可以看很多信息，比如使用jmap -histo <pid>打印对象的实例数和对象占用的内存
![]()
jmap -finalizerinfo <pid> 打印正在等候回收的对象
![]()
-小tips
对于一些应用内存已经占满了，jstack 和 jmap 可能会连不上的情况，可以使用-F参数强制打印线程或者 dump 文件，但是要注意这两者使用的用户必须与 java 进程启动用户一致，并且使用的 jdk 也要一致
-]]>
-
- Java
- Thread dump
- 问题排查
- 工具
-
-
- Java
- JPS
- JStack
- JMap
-
-
-
- 聊聊 mysql 的 MVCC 续篇
- /2020/05/02/%E8%81%8A%E8%81%8A-mysql-%E7%9A%84-MVCC-%E7%BB%AD%E7%AF%87/
- 上一篇聊了mysql 的 innodb 引擎基于 read view 实现的 mvcc 和事务隔离级别，可能有些细心的小伙伴会发现一些问题，第一个是在 RC 级别下的事务提交后的可见性，这里涉及到了三个参数，m_low_limit_id，m_up_limit_id，m_ids，之前看到知乎的一篇写的非常不错的文章，但是就在这一点上似乎有点疑惑，这里基于源码和注释来解释下这个问题
-/**
-Opens a read view where exactly the transactions serialized before this
-point in time are seen in the view.
-@param id Creator transaction id */
+ this.createTempFile();
+ this.addScheduleTask();
+ this.shutdown = false;
+ }
-void ReadView::prepare(trx_id_t id) {
- ut_ad(mutex_own(&trx_sys->mutex));
- m_creator_trx_id = id;
- m_low_limit_no = m_low_limit_id = m_up_limit_id = trx_sys->max_trx_id;
-m_low_limit_id赋的值是trx_sys->max_trx_id，代表的是当前系统最小的未分配的事务 id，所以呢，举个例子，当前有三个活跃事务，事务 id 分别是 100，200，300，而 m_up_limit_id = 100, m_low_limit_id = 301，当事务 id 是 200 的提交之后，它的更新就是可以被 100 和 300 看到，而不是说 m_ids 里没了 200，并且 200 比 100 大就应该不可见了
-幻读
还有一个问题是幻读的问题，这貌似也是个高频面试题，啥意思呢，或者说跟它最常拿来比较的脏读，脏读是指读到了别的事务未提交的数据，因为未提交，严格意义上来讲，不一定是会被最后落到库里，可能会回滚，也就是在 read uncommitted 级别下会出现的问题，但是幻读不太一样，幻读是指两次查询的结果数量不一样，比如我查了第一次是 select * from table1 where id < 10 for update,查出来了一条结果 id 是 5，然后再查一下发现出来了一条 id 是 5，一条 id 是 7，那是不是有点尴尬了，其实呢这个点我觉得脏读跟幻读也比较是从原理层面来命名，如果第一次接触的同学发觉有点不理解也比较正常，因为从逻辑上讲总之都是数据不符合预期，但是基于源码层面其实是不同的情况，幻读是在原先的 read view 无法完全解决的，怎么解决呢，简单的来说就是锁咯，我们知道innodb 是基于 record lock 行锁的，但是貌似没有办法解决这种问题，那么 innodb 就引入了 gap lock 间隙锁，比如上面说的情况下，id 小于 10 的情况下，是都应该锁住的，gap lock 其实是基于索引结构来锁的，因为索引树除了树形结构之外，还有一个next record 的指针，gap lock 也是基于这个来锁的
看一下 mysql 的文档
-
-SELECT … FOR UPDATE sets an exclusive next-key lock on every record the search encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
-
-对于一个 for update 查询，在 RR 级别下，会设置一个 next-key lock在每一条被查询到的记录上，next-lock 又是啥呢，其实就是 gap 锁和 record 锁的结合体，比如我在数据库里有 id 是 1，3，5，7，10，对于上面那条查询，查出来的结果就是 1，3，5，7，那么按照文档里描述的，对于这几条记录都会加上next-key lock，也就是(-∞, 1], (1, 3], (3, 5], (5, 7], (7, 10) 这些区间和记录会被锁起来，不让插入，再唠叨一下呢，就是其实如果是只读的事务，光 read view 一致性读就够了，如果是有写操作的呢，就需要锁了。
+调用DefaultMessageStore.start方法启动DefaultMessageStore对象中的一些服务线程。
+
+- 启动ReputMessageService服务线程
+- 启动FlushConsumeQueueService服务线程；
+- 调用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，基本上启动过程就完成了
]]>
- Mysql
- C
- 数据结构
- 源码
- Mysql
+ MQ
+ RocketMQ
+ 消息队列
+ RocketMQ
+ 中间件
+ RocketMQ
- mysql
- 数据结构
- 源码
- mvcc
- read view
- gap lock
- next-key lock
- 幻读
+ MQ
+ 消息队列
+ RocketMQ
+ 削峰填谷
+ 中间件
+ 源码解析
+ Broker
- 聊聊 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 也是基于这样去实现的
+ 聊聊 dubbo 的线程池
+ /2021/04/04/%E8%81%8A%E8%81%8A-dubbo-%E7%9A%84%E7%BA%BF%E7%A8%8B%E6%B1%A0/
+ 之前没注意到这一块，只是比较模糊的印象 dubbo 自己基于 ThreadPoolExecutor 定义了几个线程池，但是没具体看过，主要是觉得就是为了避免使用 jdk 自带的那几个(java.util.concurrent.Executors)，防止出现那些问题
看下代码目录主要是这几个
![]()
+
+- FixedThreadPool：创建一个复用固定个数线程的线程池。
简单看下代码public Executor getExecutor(URL url) {
+ String name = url.getParameter("threadname", "Dubbo");
+ int threads = url.getParameter("threads", 200);
+ int queues = url.getParameter("queues", 0);
+ return new ThreadPoolExecutor(threads, threads, 0L, TimeUnit.MILLISECONDS, (BlockingQueue)(queues == 0 ? new SynchronousQueue() : (queues < 0 ? new LinkedBlockingQueue() : new LinkedBlockingQueue(queues))), new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
+ }
+可以看到核心线程数跟最大线程数一致，也就是说就不会在核心线程数和最大线程数之间动态变化了
+- LimitedThreadPool：创建一个线程池，这个线程池中线程个数随着需要量动态增加，但是数量不超过配置的阈值的个数，另外空闲线程不会被回收，会一直存在。
public Executor getExecutor(URL url) {
+ String name = url.getParameter("threadname", "Dubbo");
+ int cores = url.getParameter("corethreads", 0);
+ int threads = url.getParameter("threads", 200);
+ int queues = url.getParameter("queues", 0);
+ return new ThreadPoolExecutor(cores, threads, 9223372036854775807L, TimeUnit.MILLISECONDS, (BlockingQueue)(queues == 0 ? new SynchronousQueue() : (queues < 0 ? new LinkedBlockingQueue() : new LinkedBlockingQueue(queues))), new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
+ }
+这个特点主要是创建了保活时间特别长，即可以认为不会被回收了
+- EagerThreadPool ：创建一个线程池，这个线程池当所有核心线程都处于忙碌状态时候，创建新的线程来执行新任务，而不是把任务放入线程池阻塞队列。
public Executor getExecutor(URL url) {
+ String name = url.getParameter("threadname", "Dubbo");
+ int cores = url.getParameter("corethreads", 0);
+ int threads = url.getParameter("threads", 2147483647);
+ int queues = url.getParameter("queues", 0);
+ int alive = url.getParameter("alive", 60000);
+ TaskQueue<Runnable> taskQueue = new TaskQueue(queues <= 0 ? 1 : queues);
+ EagerThreadPoolExecutor executor = new EagerThreadPoolExecutor(cores, threads, (long)alive, TimeUnit.MILLISECONDS, taskQueue, new NamedThreadFactory(name, true), new AbortPolicyWithReport(name, url));
+ taskQueue.setExecutor(executor);
+ return executor;
+ }
+这个是改动最多的一个了，因为需要实现这个机制，有兴趣的可以详细看下
+- CachedThreadPool： 创建一个自适应线程池，当线程处于空闲1分钟时候，线程会被回收，当有新请求到来时候会创建新线程
public Executor getExecutor(URL url) {
+ String name = url.getParameter("threadname", "Dubbo");
+ int cores = url.getParameter("corethreads", 0);
+ int threads = url.getParameter("threads", 2147483647);
+ 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，保活时间是一分钟
只是非常简略的介绍下，有兴趣可以自行阅读代码。
+
]]>
Java
+ Dubbo - 线程池
+ Dubbo
+ 线程池
+ ThreadPool
Java
- Sharding-Jdbc
+ Dubbo
+ ThreadPool
+ 线程池
+ FixedThreadPool
+ LimitedThreadPool
+ EagerThreadPool
+ CachedThreadPool
- 聊聊 mysql 的 MVCC 续续篇之锁分析
- /2020/05/10/%E8%81%8A%E8%81%8A-mysql-%E7%9A%84-MVCC-%E7%BB%AD%E7%BB%AD%E7%AF%87%E4%B9%8B%E5%8A%A0%E9%94%81%E5%88%86%E6%9E%90/
- 看完前面两篇水文之后，感觉不得不来分析下 mysql 的锁了，其实前面说到幻读的时候是有个前提没提到的，比如一个select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的，当然这里是指在 RR 或者 RC 隔离级别下，
看一段 mysql官方文档
-
-SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
-
-纯粹的这种一致性读，实际读取的是快照，也就是基于 read view 的读取方式，除非当前隔离级别是SERIALIZABLE
但是对于以下几类
-
-select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;
-除了第一条是 S 锁之外，其他都是 X 排他锁，这边在顺带下，S 锁表示共享锁， X 表示独占锁，同为 S 锁之间不冲突，S 与 X，X 与 S，X 与 X 之间都冲突，也就是加了前者，后者就加不上了
我们知道对于 RC 级别会出现幻读现象，对于 RR 级别不会出现，主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁，那么是不是 RR 级别下以上所有的都是要加 gap 锁呢，当然不是
举个例子，RR 事务隔离级别下，table1 有个主键id 字段
select * from table1 where id = 10 for update
这条语句要加 gap 锁吗？
答案是不需要，这里其实算是我看了这么久的一点自己的理解，啥时候要加 gap 锁，判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致，我上面这条查询语句，在什么情况下会出现查询结果数量不一致呢，只要在这条记录被更新或者删除的时候，有没有可能我第一次查出来一条，第二次变成两条了呢，不可能，因为是主键索引。
再变更下这个题的条件，当 id 不是主键，但是是唯一索引，这样需要怎么加锁，注意问题是怎么加锁，不是需不需要加 gap 锁，这里呢就是稍微延伸一下，把聚簇索引（主键索引）和二级索引带一下，当 id 不是主键，说明是个二级索引，但是它是唯一索引，体会下，首先对于 id = 10这个二级索引肯定要加锁，要不要锁 gap 呢，不用，因为是唯一索引，id = 10 只可能有这一条记录，然后呢，这样是不是就好了，还不行，因为啥，因为它是二级索引，对应的主键索引的记录才是真正的数据，万一被更新掉了咋办，所以在 id = 10 对应的主键索引上也需要加上锁（默认都是 record lock行锁），那主键索引上要不要加 gap 呢，也不用，也是精确定位到这一条记录
最后呢，当 id 不是主键，也不是唯一索引，只是个普通的索引，这里就需要大名鼎鼎的 gap 锁了，
是时候画个图了
![]()
其实核心的目的还是不让这个 id=10 的记录不会出现幻读，那么就需要在 id 这个索引上加上三个 gap 锁，主键索引上就不用了，在 id 索引上已经控制住了id = 10 不会出现幻读，主键索引上这两条对应的记录已经锁了，所以就这样 OK 了
-]]>
-
- Mysql
- C
- 数据结构
- 源码
- Mysql
-
-
- mysql
- 数据结构
- 源码
- mvcc
- read view
- gap lock
- next-key lock
- 幻读
-
-
-
- 聊聊 mysql 的 MVCC
- /2020/04/26/%E8%81%8A%E8%81%8A-mysql-%E7%9A%84-MVCC/
- 很久以前，有位面试官问到，你知道 mysql 的事务隔离级别吗，“额 O__O …，不太清楚”，完了之后我就去网上找相关的文章，找到了这篇MySQL 四种事务隔离级的说明, 文章写得特别好，看了这个就懂了各个事务隔离级别都是啥，不过看了这个之后多思考一下的话还是会发现问题，这么神奇的事务隔离级别是怎么实现的呢
-其中 innodb 的事务隔离用到了标题里说到的 mvcc，Multiversion concurrency control, 直译过来就是多版本并发控制，先不讲这个究竟是个啥，考虑下如果纯猜测，这个事务隔离级别应该会是怎么样实现呢，愚钝的我想了下，可以在事务开始的时候拷贝一个表，这个可以支持 RR 级别，RC 级别就不支持了，而且要是个非常大的表，想想就不可行
-腆着脸说虽然这个不可行，但是思路是对的，具体实行起来需要做一系列（肥肠多）的改动，首先根据我的理解，其实这个拷贝一个表是变成拷贝一条记录，但是如果有多个事务，那就得拷贝多次，这个问题其实可以借助版本管理系统来解释，在用版本管理系统，git 之类的之前，很原始的可能是开发完一个功能后，就打个压缩包用时间等信息命名，然后如果后面要找回这个就直接用这个压缩包的就行了，后来有了 svn，git 中心式和分布式的版本管理系统，它的一个特点是粒度可以控制到文件和代码行级别，对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别，可能之前很多人都了解过，数据库的一行记录除了我们用户自定义的字段，还有一些额外的字段，去源码data0type.h里捞一下
-/* Precise data types for system columns and the length of those columns;
-NOTE: the values must run from 0 up in the order given! All codes must
-be less than 256 */
-#define DATA_ROW_ID 0 /* row id: a 48-bit integer */
-#define DATA_ROW_ID_LEN 6 /* stored length for row id */
-
-/** Transaction id: 6 bytes */
-constexpr size_t DATA_TRX_ID = 1;
-
-/** Transaction ID type size in bytes. */
-constexpr size_t DATA_TRX_ID_LEN = 6;
-
-/** Rollback data pointer: 7 bytes */
-constexpr size_t DATA_ROLL_PTR = 2;
-
-/** Rollback data pointer type size in bytes. */
-constexpr size_t DATA_ROLL_PTR_LEN = 7;
-
-一个是 DATA_ROW_ID，这个是在数据没指定主键的时候会生成一个隐藏的，如果用户有指定主键就是主键了
-一个是 DATA_TRX_ID，这个表示这条记录的事务 ID
-还有一个是 DATA_ROLL_PTR 指向回滚段的指针
-指向的回滚段其实就是我们常说的 undo log，这里面的具体结构就是个链表，在 mvcc 里会使用到这个，还有就是这个 DATA_TRX_ID，每条记录都记录了这个事务 ID，表示的是这条记录的当前值是被哪个事务修改的，下面就扯回事务了，我们知道 Read Uncommitted， 其实用不到隔离，直接读取当前值就好了，到了 Read Committed 级别，我们要让事务读取到提交过的值，mysql 使用了一个叫 read view 的玩意，它里面有这些值是我们需要注意的，
-m_low_limit_id, 这个是 read view 创建时最大的活跃事务 id
-m_up_limit_id, 这个是 read view 创建时最小的活跃事务 id
-m_ids, 这个是 read view 创建时所有的活跃事务 id 数组
-m_creator_trx_id 这个是当前记录的创建事务 id
-判断事务的可见性主要的逻辑是这样，
-
-- 当记录的事务
id 小于最小活跃事务 id，说明是可见的，
-- 如果记录的事务
id 等于当前事务 id，说明是自己的更改，可见
-- 如果记录的事务
id 大于最大的活跃事务 id, 不可见
-- 如果记录的事务
id 介于 m_low_limit_id 和 m_up_limit_id 之间，则要判断它是否在 m_ids 中，如果在，不可见，如果不在，表示已提交，可见
具体的代码捞一下看看/** Check whether the changes by id are visible.
- @param[in] id transaction id to check against the view
- @param[in] name table name
- @return whether the view sees the modifications of id. */
- bool changes_visible(trx_id_t id, const table_name_t &name) const
- MY_ATTRIBUTE((warn_unused_result)) {
- ut_ad(id > 0);
-
- if (id < m_up_limit_id || id == m_creator_trx_id) {
- return (true);
- }
-
- check_trx_id_sanity(id, name);
-
- if (id >= m_low_limit_id) {
- return (false);
-
- } else if (m_ids.empty()) {
- return (true);
- }
-
- const ids_t::value_type *p = m_ids.data();
-
- return (!std::binary_search(p, p + m_ids.size(), id));
- }
-剩下来一点是啥呢，就是 Read Committed 和 Repeated Read 也不一样，那前面说的 read view 都能支持吗，又是怎么支持呢，假如这个 read view 是在事务一开始就创建，那好像能支持的只是 RR 事务隔离级别，其实呢，这是通过创建 read view的时机，对于 RR 级别，就是在事务的第一个 select 语句是创建，对于 RC 级别，是在每个 select 语句执行前都是创建一次，那样就可以保证能读到所有已提交的数据
-
-]]>
-
- Mysql
- C
- 数据结构
- 源码
- Mysql
-
-
- mysql
- 数据结构
- 源码
- mvcc
- read view
-
-
-
- 聊聊 mysql 索引的一些细节
- /2020/12/27/%E8%81%8A%E8%81%8A-mysql-%E7%B4%A2%E5%BC%95%E7%9A%84%E4%B8%80%E4%BA%9B%E7%BB%86%E8%8A%82/
- 前几天同事问了我个 mysql 索引的问题，虽然大概知道，但是还是想来实践下，就是 is null，is not null 这类查询是否能用索引，可能之前有些网上的文章说都是不能用索引，但是其实不是，我们来看个小试验
-CREATE TABLE `null_index_t` (
- `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
- `null_key` varchar(255) DEFAULT NULL,
- `null_key1` varchar(255) DEFAULT NULL,
- `null_key2` varchar(255) DEFAULT NULL,
- PRIMARY KEY (`id`),
- KEY `idx_1` (`null_key`) USING BTREE,
- KEY `idx_2` (`null_key1`) USING BTREE,
- KEY `idx_3` (`null_key2`) USING BTREE
-) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-用个存储过程来插入数据
-
-delimiter $ #以delimiter来标记用$表示存储过程结束
-create procedure nullIndex1()
-begin
-declare i int;
-declare j int;
-set i=1;
-set j=1;
-while(i<=100) do
- while(j<=100) do
- IF (i % 3 = 0) THEN
- INSERT INTO null_index_t ( `null_key`, `null_key1`, `null_key2` ) VALUES (null , LEFT(MD5(RAND()), 8), LEFT(MD5(RAND()), 8));
- ELSEIF (i % 3 = 1) THEN
- INSERT INTO null_index_t ( `null_key`, `null_key1`, `null_key2` ) VALUES (LEFT(MD5(RAND()), 8), NULL, LEFT(MD5(RAND()), 8));
- ELSE
- INSERT INTO null_index_t ( `null_key`, `null_key1`, `null_key2` ) VALUES (LEFT(MD5(RAND()), 8), LEFT(MD5(RAND()), 8), NULL);
- END IF;
- set j=j+1;
- end while;
- set i=i+1;
- set j=1;
-end while;
-end
-$
-call nullIndex1();
-然后看下我们的 is null 查询
-EXPLAIN select * from null_index_t WHERE null_key is null;
-![]()
再来看看另一个
-EXPLAIN select * from null_index_t WHERE null_key is not null;
-![]()
从这里能看出来啥呢，可以思考下
-从上面可以发现，is null应该是用上了索引了，所以至少不是一刀切不能用，但是看着is not null好像不太行额
我们在做一点小改动，把这个表里的数据改成 9100 条是 null，剩下 900 条是有值的，然后再执行下
![]()
然后再来看看执行结果
-EXPLAIN select * from null_index_t WHERE null_key is null;
-![]()
-EXPLAIN select * from null_index_t WHERE null_key is not null;
-![]()
是不是不一样了，这里再补充下我试验使用的 mysql 是 5.7 的，不保证在其他版本的一致性，
其实可以看出随着数据量的变化，mysql 会不会使用索引是会变化的，不是说 is not null 一定会使用，也不是一定不会使用，而是优化器会根据查询成本做个预判，这个预判尽可能会减小查询成本，主要包括回表啥的，但是也不一定完全准确。
-]]>
-
- Mysql
- C
- 索引
- Mysql
-
-
- mysql
- 索引
- is null
- is not null
- procedure
-
-
-
- 聊聊 redis 缓存的应用问题
- /2021/01/31/%E8%81%8A%E8%81%8A-redis-%E7%BC%93%E5%AD%98%E7%9A%84%E5%BA%94%E7%94%A8%E9%97%AE%E9%A2%98/
- 前面写过一系列的 redis 源码分析的，但是实际上很多的问题还是需要结合实际的使用，然后其实就避不开缓存使用的三个著名问题，穿透，击穿和雪崩，这三个概念也是有着千丝万缕的关系，
-缓存穿透
缓存穿透是指当数据库中本身就不存在这个数据的时候，使用一般的缓存策略时访问不到缓存后就访问数据库，但是因为数据库也没数据，所以如果不做任何策略优化的话，这类数据就每次都会访问一次数据库，对数据库压力也会比较大。
-缓存击穿
缓存击穿跟穿透比较类似的，都是访问缓存不在，然后去访问数据库，与穿透不一样的是击穿是在数据库中存在数据，但是可能由于第一次访问，或者缓存过期了，需要访问到数据库，这对于访问量小的情况其实算是个正常情况，但是随着请求量变高就会引发一些性能隐患。
-缓存雪崩
缓存雪崩就是击穿的大规模集群效应，当大量的缓存过期失效的时候，这些请求都是直接访问到数据库了，会对数据库造成很大的压力。
-对于以上三种场景也有一些比较常见的解决方案，但也不能说是万无一失的，需要随着业务去寻找合适的方案
-解决缓存穿透
对于数据库中就没这个数据的时候，一种是可以对这个 key 设置下空值，即以一个特定的表示是数据库不存在的，这种情况需要合理地调整过期时间，当这个 key 在数据库中有数据了的话，也需要有策略去更新这个值，并且如果这类 key 非常多，这个方法就会不太合适，就可以使用第二种方法，就是布隆过滤器，bloom filter，前置一个布隆过滤器，当这个 key 在数据库不存在的话，先用布隆过滤器挡一道，如果不在的话就直接返回了，当然布隆过滤器不是绝对的准确的
-解决缓存击穿
当一个 key 的缓存过期了，如果大量请求过来访问这个 key，请求都会落在数据库里，这个时候就可以使用一些类似于互斥锁的方式去让一个线程去访问数据库，更新缓存，但是这里其实也有个问题，就是如果是热点 key 其实这种方式也比较危险，万一更新失败，或者更新操作的时候耗时比较久，就会有一大堆请求卡在那，这种情况可能需要有一些异步提前刷新缓存，可以结合具体场景选择方式
-解决缓存雪崩
雪崩的情况是指大批量的 key 都一起过期了，击穿的放大版，大批量的请求都打到数据库上了，一方面有可能直接缓存不可用了，就需要用集群化高可用的缓存服务，然后对于实际使用中也可以使用本地缓存结合 redis 缓存，去提高可用性，再配合一些限流措施，然后就是缓存使用过程总的过期时间最好能加一些随机值，防止在同一时间过期而导致雪崩，结合互斥锁防止大量请求打到数据库。
-]]>
-
- Redis
- 应用
- 缓存
- 缓存
- 穿透
- 击穿
- 雪崩
-
-
- Redis
- 缓存穿透
- 缓存击穿
- 缓存雪崩
- 布隆过滤器
- bloom filter
- 互斥锁
-
-
-
- 聊聊Java中的单例模式
- /2019/12/21/%E8%81%8A%E8%81%8AJava%E4%B8%AD%E7%9A%84%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F/
- 这是个 Java 面试的高频问题，我也遇到过，以往都是觉得这类题没意思，网上一搜一大堆，也不愿意记，其实说回来，主要还是没静下心来好好去理解，今天无意中看到一个课程，基本帮我把一些疑惑的点讲清楚了，首先单例是啥意思，这个其实是有范围一说，比如我起了个Spring Boot应用，在这个应用范围内，我的常规 bean 是单例的，意味着 getBean 的时候其实永远只会拿到那一个对象，那要怎么来写一个单例呢，首先就是传说中的饿汉模式，也是最简单的
-饿汉模式
public class Singleton1 {
- // 首先，将构造方法变成私有的
- private Singleton1() {};
- // 创建私有静态实例，这样第一次使用的时候就会进行创建
- private static Singleton instance = new Singleton1();
-
- // 使用这个对象都是通过这个 getInstance 来获取
- public static Singleton1 getInstance() {
- return instance;
- }
- // 瞎写一个静态方法。这里想说的是，如果我们只是要调用 Singleton.getDate(...)，
- // 本来是不想要生成 Singleton 实例的，不过没办法，已经生成了
- public static Date getDate(String mode) {return new Date();}
-}
-上面借鉴了一些代码，其实这是最基本，也不会错的方法，但是正如其中getDate方法里说的问题，有时候并没有想那这个对象，但是因为我调用了这个类的静态方法，导致对象已经生成了，可能这也是饿汉模式名字的来由，不管三七二十一给你生成个单例就完事了，不管有没有用，但是这种个人觉得也没啥大问题，如果是面试的话最好说出来它的缺点
-饱汉模式
public class Singleton2 {
- // 首先，也是先堵死 new Singleton() 这条路,将构造方法变成私有
- private Singleton2() {}
- // 和饿汉模式相比，这边不需要先实例化出来，注意这里的 volatile，它是必须的
- private static volatile Singleton2 instance = null;
-
- private int m = 9;
-
- public static Singleton getInstance() {
- if (instance == null) {
- // 加锁
- synchronized (Singleton2.class) {
- // 这一次判断也是必须的，不然会有并发问题
- if (instance == null) {
- instance = new Singleton2();
- }
- }
- }
- return instance;
- }
-}
-这里容易错的有三点，理解了其实就比较好记了
-第一点，为啥不在 getInstance 上整个代码块加 synchronized，这个其实比较容易理解，就是锁的力度太大，性能太差了，这点其实也要去理解，可以举个夸张的例子，比如我一个电商的服务，如果为了避免一个人的订单出现问题，是不是可以从请求入口就把他锁住，到请求结束释放，那么里面做的事情都有保障，然而这显然不可能，因为我们想要这种竞态条件抢占资源的时间尽量减少，防止其他线程等待。
第二点，为啥synchronized之已经检查了 instance == null,还要在里面再检查一次，这个有个术语，叫 double check lock,但是为啥要这么做呢，其实很简单，想象当有两个线程，都过了第一步为空判断，这个时候只有一个线程能拿到这个锁，另一个线程就等待了，如果不再判断一次，那么第一个线程新建完对象释放锁之后，第二个线程又能拿到锁，再去创建一个对象。
第三点，为啥要volatile关键字，原先对它的理解是它修饰的变量在 JMM 中能及时将变量值写到主存中，但是它还有个很重要的作用，就是防止指令重排序，instance = new Singleton();这行代码其实在底层是分成三条指令执行的，第一条是在堆上申请了一块内存放这个对象，但是对象的字段啥的都还是默认值，第二条是设置对象的值，比如上面的 m 是 9，然后第三条是将这个对象和虚拟机栈上的指针建立引用关联，那么如果我不用volatile关键字，这三条指令就有可能出现重排，比如变成了 1-3-2 这种顺序，当执行完第二步时，有个线程来访问这个对象了，先判断是不是空，发现不是空的，就拿去直接用了，是不是就出现问题了，所以这个volatile也是不可缺少的
-嵌套类
public class Singleton3 {
-
- private Singleton3() {}
- // 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法 的特性
- private static class Holder {
- private static Singleton3 instance = new Singleton3();
- }
- public static Singleton3 getInstance() {
- return Holder.instance;
- }
-}
-这个我个人感觉是饿汉模式的升级版，可以在调用getInstance的时候去实例化对象，也是比较推荐的
-枚举单例
public enum Singleton {
- INSTANCE;
-
- public void doSomething(){
- //todo doSomething
- }
-}
-枚举很特殊，它在类加载的时候会初始化里面的所有的实例，而且 JVM 保证了它们不会再被实例化，所以它天生就是单例的。
-]]>
-
- Java
- Design Patterns
- Singleton
-
-
- 设计模式
- Design Patterns
- 单例
- Singleton
-
-
-
- 聊聊 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
+ 聊聊 mysql 的 MVCC 续篇
+ /2020/05/02/%E8%81%8A%E8%81%8A-mysql-%E7%9A%84-MVCC-%E7%BB%AD%E7%AF%87/
+ 上一篇聊了mysql 的 innodb 引擎基于 read view 实现的 mvcc 和事务隔离级别，可能有些细心的小伙伴会发现一些问题，第一个是在 RC 级别下的事务提交后的可见性，这里涉及到了三个参数，m_low_limit_id，m_up_limit_id，m_ids，之前看到知乎的一篇写的非常不错的文章，但是就在这一点上似乎有点疑惑，这里基于源码和注释来解释下这个问题
+/**
+Opens a read view where exactly the transactions serialized before this
+point in time are seen in the view.
+@param id Creator transaction id */
-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
+void ReadView::prepare(trx_id_t id) {
+ ut_ad(mutex_own(&trx_sys->mutex));
-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 条数据再进行合并排序就可以获得最终正确的结果。
这个就是传说中的二次查询法。
+ m_creator_trx_id = id;
+
+ m_low_limit_no = m_low_limit_id = m_up_limit_id = trx_sys->max_trx_id;
+m_low_limit_id赋的值是trx_sys->max_trx_id，代表的是当前系统最小的未分配的事务 id，所以呢，举个例子，当前有三个活跃事务，事务 id 分别是 100，200，300，而 m_up_limit_id = 100, m_low_limit_id = 301，当事务 id 是 200 的提交之后，它的更新就是可以被 100 和 300 看到，而不是说 m_ids 里没了 200，并且 200 比 100 大就应该不可见了
+幻读
还有一个问题是幻读的问题，这貌似也是个高频面试题，啥意思呢，或者说跟它最常拿来比较的脏读，脏读是指读到了别的事务未提交的数据，因为未提交，严格意义上来讲，不一定是会被最后落到库里，可能会回滚，也就是在 read uncommitted 级别下会出现的问题，但是幻读不太一样，幻读是指两次查询的结果数量不一样，比如我查了第一次是 select * from table1 where id < 10 for update,查出来了一条结果 id 是 5，然后再查一下发现出来了一条 id 是 5，一条 id 是 7，那是不是有点尴尬了，其实呢这个点我觉得脏读跟幻读也比较是从原理层面来命名，如果第一次接触的同学发觉有点不理解也比较正常，因为从逻辑上讲总之都是数据不符合预期，但是基于源码层面其实是不同的情况，幻读是在原先的 read view 无法完全解决的，怎么解决呢，简单的来说就是锁咯，我们知道innodb 是基于 record lock 行锁的，但是貌似没有办法解决这种问题，那么 innodb 就引入了 gap lock 间隙锁，比如上面说的情况下，id 小于 10 的情况下，是都应该锁住的，gap lock 其实是基于索引结构来锁的，因为索引树除了树形结构之外，还有一个next record 的指针，gap lock 也是基于这个来锁的
看一下 mysql 的文档
+
+SELECT … FOR UPDATE sets an exclusive next-key lock on every record the search encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
+
+对于一个 for update 查询，在 RR 级别下，会设置一个 next-key lock在每一条被查询到的记录上，next-lock 又是啥呢，其实就是 gap 锁和 record 锁的结合体，比如我在数据库里有 id 是 1，3，5，7，10，对于上面那条查询，查出来的结果就是 1，3，5，7，那么按照文档里描述的，对于这几条记录都会加上next-key lock，也就是(-∞, 1], (1, 3], (3, 5], (5, 7], (7, 10) 这些区间和记录会被锁起来，不让插入，再唠叨一下呢，就是其实如果是只读的事务，光 read view 一致性读就够了，如果是有写操作的呢，就需要锁了。
+]]>
+
+ C
+ Mysql
+ 数据结构
+ 源码
+ Mysql
+
+
+ mysql
+ 数据结构
+ 源码
+ mvcc
+ read view
+ gap lock
+ next-key lock
+ 幻读
+
+
+
+ 聊聊 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
@@ -13224,221 +12724,348 @@ t2
- 聊聊一次 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/
- 熟悉我的人（谁熟悉你啊🙄）知道我以前写过 PHP，虽然现在在工作中没用到了，但是自己的一些小工具还是会用 PHP 来写，但是在 Mac 碰到了一个环境相关的问题，因为我也是个更新狂魔，用了 brew 之后因为 gfw 的原因，如果长时间不更新，有时候要装一个用它装一个软件的话，前置的更新耗时就会让人非常头大，所以我基本会隔天 update 一下，但是这样会带来一个很心烦的问题，就是像这样，因为我是要用一个固定版本的 PHP，如果一直升需要一直配扩展啥的也很麻烦，如果一直升级 PHP 到最新版可能会比较少碰到这个问题
-dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.64.dylib
-这是什么鬼啊，然后我去这个目录下看了下，已经都是libicui18n.67.dylib了，而且它没有把原来的版本保留下来，首先这个是个叫 icu4c是啥玩意，谷歌了一下
+ 聊聊 mysql 的 MVCC 续续篇之锁分析
+ /2020/05/10/%E8%81%8A%E8%81%8A-mysql-%E7%9A%84-MVCC-%E7%BB%AD%E7%BB%AD%E7%AF%87%E4%B9%8B%E5%8A%A0%E9%94%81%E5%88%86%E6%9E%90/
+ 看完前面两篇水文之后，感觉不得不来分析下 mysql 的锁了，其实前面说到幻读的时候是有个前提没提到的，比如一个select * from table1 where id = 1这种查询语句其实是不会加传说中的锁的，当然这里是指在 RR 或者 RC 隔离级别下，
看一段 mysql官方文档
-ICU4C是ICU在C/C++平台下的版本, ICU(International Component for Unicode)是基于”IBM公共许可证”的，与开源组织合作研究的, 用于支持软件国际化的开源项目。ICU4C提供了C/C++平台强大的国际化开发能力，软件开发者几乎可以使用ICU4C解决任何国际化的问题，根据各地的风俗和语言习惯，实现对数字、货币、时间、日期、和消息的格式化、解析，对字符串进行大小写转换、整理、搜索和排序等功能，必须一提的是，ICU4C提供了强大的BIDI算法，对阿拉伯语等BIDI语言提供了完善的支持。
+SELECT ... FROM is a consistent read, reading a snapshot of the database and setting no locks unless the transaction isolation level is set to SERIALIZABLE. For SERIALIZABLE level, the search sets shared next-key locks on the index records it encounters. However, only an index record lock is required for statements that lock rows using a unique index to search for a unique row.
-然后首先想到的解决方案就是能不能我使用brew install icu4c@64来重装下原来的版本，发现不行，并木有，之前的做法就只能是去网上把 64 的下载下来，然后放到这个目录，比较麻烦不智能，虽然没抱着希望在谷歌着，不过这次竟然给我找到了一个我认为非常 nice 的解决方案，因为是在 Stack Overflow 找到的，本着写给像我这样的小小白看的，那就稍微翻译一下
第一步，我们到 brew的目录下
-cd $(brew --prefix)/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
-这个可以理解为是 maven 的 pom 文件，不过有很多不同之处，使用ruby 写的，然后一个文件对应一个组件或者软件，那我们看下有个叫icu4c.rb的文件，
第二步看看它的提交历史
-git log --follow icu4c.rb
-在 git log 的海洋中寻找，寻找它的(64版本)的身影
![]()
第三步注意这三个红框，Stack Overflow 给出来的答案这一步是找到这个 commit id 直接切出一个新分支
-git checkout -b icu4c-63 e7f0f10dc63b1dc1061d475f1a61d01b70ef2cb7
-其实注意 commit id 旁边的红框，这个是有tag 的，可以直接
-git checkout icu4c-64
-PS: 因为我的问题是出在 64 的问题，Stack Overflow 回答的是 63 的，反正是一样的解决方法
第四部，切回去之后我们就可以用 brew 提供的基于文件的安装命令来重新装上 64 版本
-brew reinstall ./icu4c.rb
-然后就是第五步，切换版本
-brew switch icu4c 64.2
-最后把分支切回来
-git checkout master
-是不是感觉很厉害的解决方法，大佬还提供了一个更牛的，直接写个 zsh 方法
-# zsh
-function hiicu64() {
- local last_dir=$(pwd)
-
- cd $(brew --prefix)/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
- git checkout icu4c-4
- brew reinstall ./icu4c.rb
- brew switch icu4c 64.2
- git checkout master
-
- cd $last_dir
-}
-对应自己的版本改改版本号就可以了，非常好用。
+纯粹的这种一致性读，实际读取的是快照，也就是基于 read view 的读取方式，除非当前隔离级别是SERIALIZABLE
但是对于以下几类
+
+select * from table where ? lock in share mode;select * from table where ? for update;insert into table values (...);update table set ? where ?;delete from table where ?;
+除了第一条是 S 锁之外，其他都是 X 排他锁，这边在顺带下，S 锁表示共享锁， X 表示独占锁，同为 S 锁之间不冲突，S 与 X，X 与 S，X 与 X 之间都冲突，也就是加了前者，后者就加不上了
我们知道对于 RC 级别会出现幻读现象，对于 RR 级别不会出现，主要的区别是 RR 级别下对于以上的加锁读取都根据情况加上了 gap 锁，那么是不是 RR 级别下以上所有的都是要加 gap 锁呢，当然不是
举个例子，RR 事务隔离级别下，table1 有个主键id 字段
select * from table1 where id = 10 for update
这条语句要加 gap 锁吗？
答案是不需要，这里其实算是我看了这么久的一点自己的理解，啥时候要加 gap 锁，判断的条件是根据我查询的数据是否会因为不加 gap 锁而出现数量的不一致，我上面这条查询语句，在什么情况下会出现查询结果数量不一致呢，只要在这条记录被更新或者删除的时候，有没有可能我第一次查出来一条，第二次变成两条了呢，不可能，因为是主键索引。
再变更下这个题的条件，当 id 不是主键，但是是唯一索引，这样需要怎么加锁，注意问题是怎么加锁，不是需不需要加 gap 锁，这里呢就是稍微延伸一下，把聚簇索引（主键索引）和二级索引带一下，当 id 不是主键，说明是个二级索引，但是它是唯一索引，体会下，首先对于 id = 10这个二级索引肯定要加锁，要不要锁 gap 呢，不用，因为是唯一索引，id = 10 只可能有这一条记录，然后呢，这样是不是就好了，还不行，因为啥，因为它是二级索引，对应的主键索引的记录才是真正的数据，万一被更新掉了咋办，所以在 id = 10 对应的主键索引上也需要加上锁（默认都是 record lock行锁），那主键索引上要不要加 gap 呢，也不用，也是精确定位到这一条记录
最后呢，当 id 不是主键，也不是唯一索引，只是个普通的索引，这里就需要大名鼎鼎的 gap 锁了，
是时候画个图了
![]()
其实核心的目的还是不让这个 id=10 的记录不会出现幻读，那么就需要在 id 这个索引上加上三个 gap 锁，主键索引上就不用了，在 id 索引上已经控制住了id = 10 不会出现幻读，主键索引上这两条对应的记录已经锁了，所以就这样 OK 了
]]>
- Mac
- PHP
- Homebrew
- icu4c
+ C
+ Mysql
+ 数据结构
+ 源码
+ Mysql
- Mac
- PHP
- Homebrew
- icu4c
- zsh
+ mysql
+ 数据结构
+ 源码
+ mvcc
+ read view
+ gap lock
+ next-key lock
+ 幻读
- 聊聊传说中的 ThreadLocal
- /2021/05/30/%E8%81%8A%E8%81%8A%E4%BC%A0%E8%AF%B4%E4%B8%AD%E7%9A%84-ThreadLocal/
- 说来也惭愧，这个 ThreadLocal 其实一直都是一知半解，而且看了一下之后还发现记错了，所以还是记录下
原先记忆里的都是反过来，一个 ThreadLocal 是里面按照 thread 作为 key，存储线程内容的，真的是半解都米有，完全是错的，这样就得用 concurrentHashMap 这种去存储并且要锁定线程了，然后内容也只能存一个了，想想简直智障
-究竟是啥结构
比如我们在代码中 new 一个 ThreadLocal，
-public static void main(String[] args) {
- ThreadLocal<Man> tl = new ThreadLocal<>();
+ 聊聊 mysql 的 MVCC
+ /2020/04/26/%E8%81%8A%E8%81%8A-mysql-%E7%9A%84-MVCC/
+ 很久以前，有位面试官问到，你知道 mysql 的事务隔离级别吗，“额 O__O …，不太清楚”，完了之后我就去网上找相关的文章，找到了这篇MySQL 四种事务隔离级的说明, 文章写得特别好，看了这个就懂了各个事务隔离级别都是啥，不过看了这个之后多思考一下的话还是会发现问题，这么神奇的事务隔离级别是怎么实现的呢
+其中 innodb 的事务隔离用到了标题里说到的 mvcc，Multiversion concurrency control, 直译过来就是多版本并发控制，先不讲这个究竟是个啥，考虑下如果纯猜测，这个事务隔离级别应该会是怎么样实现呢，愚钝的我想了下，可以在事务开始的时候拷贝一个表，这个可以支持 RR 级别，RC 级别就不支持了，而且要是个非常大的表，想想就不可行
+腆着脸说虽然这个不可行，但是思路是对的，具体实行起来需要做一系列（肥肠多）的改动，首先根据我的理解，其实这个拷贝一个表是变成拷贝一条记录，但是如果有多个事务，那就得拷贝多次，这个问题其实可以借助版本管理系统来解释，在用版本管理系统，git 之类的之前，很原始的可能是开发完一个功能后，就打个压缩包用时间等信息命名，然后如果后面要找回这个就直接用这个压缩包的就行了，后来有了 svn，git 中心式和分布式的版本管理系统，它的一个特点是粒度可以控制到文件和代码行级别，对应的我们的 mysql 事务是不是也可以从一开始预想的表级别细化到行的级别，可能之前很多人都了解过，数据库的一行记录除了我们用户自定义的字段，还有一些额外的字段，去源码data0type.h里捞一下
+/* Precise data types for system columns and the length of those columns;
+NOTE: the values must run from 0 up in the order given! All codes must
+be less than 256 */
+#define DATA_ROW_ID 0 /* row id: a 48-bit integer */
+#define DATA_ROW_ID_LEN 6 /* stored length for row id */
- new Thread(() -> {
- try {
- TimeUnit.SECONDS.sleep(2);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- System.out.println(tl.get());
- }).start();
- new Thread(() -> {
- try {
- TimeUnit.SECONDS.sleep(1);
- } catch (InterruptedException e) {
- e.printStackTrace();
- }
- tl.set(new Man());
- }).start();
- }
+/** Transaction id: 6 bytes */
+constexpr size_t DATA_TRX_ID = 1;
- static class Man {
- String name = "nick";
- }
-这里构造了两个线程，一个先往里设值，一个后从里取，运行看下结果，
![]()
知道这个用法的话肯定知道是取不到值的，只是具体的原理原来搞错了，我们来看下设值 set 方法
-public void set(T value) {
- Thread t = Thread.currentThread();
- ThreadLocalMap map = getMap(t);
- if (map != null)
- map.set(this, value);
- else
- createMap(t, value);
-}
-写博客这会我才明白我原来咋会错得这么离谱，看到第一行代码 t 就是当前线程，然后第二行就是用这个线程去getMap，然后我是把这个当成从 map 里取值了，其实这里是
-ThreadLocalMap getMap(Thread t) {
- return t.threadLocals;
-}
-获取 t 的 threadLocals 成员变量，那这个 threadLocals 又是啥呢
![]()
它其实是线程 Thread 中的一个类型是java.lang.ThreadLocal.ThreadLocalMap的成员变量
这是 ThreadLocal 的一个静态成员变量
-static class ThreadLocalMap {
+/** Transaction ID type size in bytes. */
+constexpr size_t DATA_TRX_ID_LEN = 6;
- /**
- * The entries in this hash map extend WeakReference, using
- * its main ref field as the key (which is always a
- * ThreadLocal object). Note that null keys (i.e. entry.get()
- * == null) mean that the key is no longer referenced, so the
- * entry can be expunged from table. Such entries are referred to
- * as "stale entries" in the code that follows.
- */
- static class Entry extends WeakReference<ThreadLocal<?>> {
- /** The value associated with this ThreadLocal. */
- Object value;
+/** Rollback data pointer: 7 bytes */
+constexpr size_t DATA_ROLL_PTR = 2;
+
+/** Rollback data pointer type size in bytes. */
+constexpr size_t DATA_ROLL_PTR_LEN = 7;
+
+一个是 DATA_ROW_ID，这个是在数据没指定主键的时候会生成一个隐藏的，如果用户有指定主键就是主键了
+一个是 DATA_TRX_ID，这个表示这条记录的事务 ID
+还有一个是 DATA_ROLL_PTR 指向回滚段的指针
+指向的回滚段其实就是我们常说的 undo log，这里面的具体结构就是个链表，在 mvcc 里会使用到这个，还有就是这个 DATA_TRX_ID，每条记录都记录了这个事务 ID，表示的是这条记录的当前值是被哪个事务修改的，下面就扯回事务了，我们知道 Read Uncommitted， 其实用不到隔离，直接读取当前值就好了，到了 Read Committed 级别，我们要让事务读取到提交过的值，mysql 使用了一个叫 read view 的玩意，它里面有这些值是我们需要注意的，
+m_low_limit_id, 这个是 read view 创建时最大的活跃事务 id
+m_up_limit_id, 这个是 read view 创建时最小的活跃事务 id
+m_ids, 这个是 read view 创建时所有的活跃事务 id 数组
+m_creator_trx_id 这个是当前记录的创建事务 id
+判断事务的可见性主要的逻辑是这样，
+
+- 当记录的事务
id 小于最小活跃事务 id，说明是可见的，
+- 如果记录的事务
id 等于当前事务 id，说明是自己的更改，可见
+- 如果记录的事务
id 大于最大的活跃事务 id, 不可见
+- 如果记录的事务
id 介于 m_low_limit_id 和 m_up_limit_id 之间，则要判断它是否在 m_ids 中，如果在，不可见，如果不在，表示已提交，可见
具体的代码捞一下看看/** Check whether the changes by id are visible.
+ @param[in] id transaction id to check against the view
+ @param[in] name table name
+ @return whether the view sees the modifications of id. */
+ bool changes_visible(trx_id_t id, const table_name_t &name) const
+ MY_ATTRIBUTE((warn_unused_result)) {
+ ut_ad(id > 0);
+
+ if (id < m_up_limit_id || id == m_creator_trx_id) {
+ return (true);
+ }
+
+ check_trx_id_sanity(id, name);
+
+ if (id >= m_low_limit_id) {
+ return (false);
+
+ } else if (m_ids.empty()) {
+ return (true);
+ }
+
+ const ids_t::value_type *p = m_ids.data();
+
+ return (!std::binary_search(p, p + m_ids.size(), id));
+ }
+剩下来一点是啥呢，就是 Read Committed 和 Repeated Read 也不一样，那前面说的 read view 都能支持吗，又是怎么支持呢，假如这个 read view 是在事务一开始就创建，那好像能支持的只是 RR 事务隔离级别，其实呢，这是通过创建 read view的时机，对于 RR 级别，就是在事务的第一个 select 语句是创建，对于 RC 级别，是在每个 select 语句执行前都是创建一次，那样就可以保证能读到所有已提交的数据
+
+]]>
+
+ C
+ Mysql
+ 数据结构
+ 源码
+ Mysql
+
+
+ mysql
+ 数据结构
+ 源码
+ mvcc
+ read view
+
+
+
+ 聊聊 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());
- Entry(ThreadLocal<?> k, Object v) {
- super(k);
- value = v;
- }
- }
- }
-全部代码有点长，只截取了一小部分，然后我们再回头来分析前面说的 set 过程，再 copy 下代码
-public void set(T value) {
- Thread t = Thread.currentThread();
- ThreadLocalMap map = getMap(t);
- if (map != null)
- map.set(this, value);
- else
- createMap(t, value);
-}
-获取到 map 以后呢，如果 map 不为空，就往 map 里 set，这里注意 key 是啥，其实是当前这个 ThreadLocal，这里就比较明白了究竟是啥结构，每个线程都会维护自身的 ThreadLocalMap，它是线程的一个成员变量，当创建 ThreadLocal 的时候，进行设值的时候其实是往这个 map 里以 ThreadLocal 作为 key，往里设 value。
-内存泄漏是什么鬼
这里又要看下前面的 ThreadLocalMap 结构了，类似 HashMap，它有个 Entry 结构，在设置的时候会先包装成一个 Entry
-private void set(ThreadLocal<?> key, Object value) {
- // We don't use a fast path as with get() because it is at
- // least as common to use set() to create new entries as
- // it is to replace existing ones, in which case, a fast
- // path would fail more often than not.
+ 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
- Entry[] tab = table;
- int len = tab.length;
- int i = key.threadLocalHashCode & (len-1);
- for (Entry e = tab[i];
- e != null;
- e = tab[i = nextIndex(i, len)]) {
- ThreadLocal<?> k = e.get();
+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
- if (k == key) {
- e.value = value;
- return;
- }
+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
- if (k == null) {
- replaceStaleEntry(key, value, i);
- return;
- }
- }
+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
- tab[i] = new Entry(key, value);
- int sz = ++size;
- if (!cleanSomeSlots(i, sz) && sz >= threshold)
- rehash();
-}
-这里其实比较重要的就是前面的 Entry 的构造方法，Entry 是个 WeakReference 的子类，然后在构造方法里可以看到 key 会被包装成一个弱引用，这里为什么使用弱引用，其实是方便这个 key 被回收，如果前面的 ThreadLocal tl实例被设置成 null 了，如果这里是直接的强引用的话，就只能等到线程整个回收了，但是其实是弱引用也会有问题，主要是因为这个 value，如果在 ThreadLocal tl 被设置成 null 了，那么其实这个 value 就会没法被访问到，所以最好的操作还是在使用完了就 remove 掉
+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
- ThreadLocal
- 弱引用
- 内存泄漏
- WeakReference
+ Sharding-Jdbc
- 聊聊厦门旅游的好与不好
- /2021/04/11/%E8%81%8A%E8%81%8A%E5%8E%A6%E9%97%A8%E6%97%85%E6%B8%B8%E7%9A%84%E5%A5%BD%E4%B8%8E%E4%B8%8D%E5%A5%BD/
- 这几天去了趟厦门，原来几年前就想去了，本来都请好假了，后面因为一些事情没去成，这次刚好公司组织，就跟 LD 一起去了厦门，也不洋洋洒洒地写游记了，后面可能会有，今天先来总结下好的地方和比较坑的地方。
这次主要去了中山路、鼓浪屿、曾厝(cuo)垵、植物园、灵玲马戏团，因为住的离环岛路比较近，还有幸现场看了下厦门马拉松，其中
-中山路
这里看上去是有点民国时期的建筑风格，部分像那种电视里的租界啥的，不过这次去的时候都在翻修，路一大半拦起来了，听导游说这里往里面走有个局口街，然后上次听前同事说厦门比较有名的就是沙茶面和海蛎煎，不出意料的不太爱吃，沙茶面比较普通，可能是没吃到正宗的，海蛎煎吃不惯，倒是有个大叔的沙茶里脊还不错，在局口街那，还有小哥在那拍，应该也算是个网红打卡点了，然后吃了个油条麻糍也还不错，总体如果是看建筑的话可能最近不是个好时间，个人也没这方面爱好，吃的话最好多打听打听沙茶面跟海蛎煎哪里正宗。如果不知道哪家好吃，也不爱看这类建筑的可以排个坑。
-鼓浪屿
鼓浪屿也是完全没啥概念，需要乘船过去，但是只要二十分钟，岛上没有机动车，基本都靠走，有几个比较有名的地方，菽庄花园，里面有钢琴博物馆，对这个感兴趣的可以去看看，旁边是沙滩还可以逛逛，然后有各种博物馆，风琴啥的，岛上最大的特色是巷子多，道听途说有三百多条小巷，还有几个网红打卡点，周杰伦晴天墙，还有个最美转角，都是挤满了人排队打卡拍照，不过如果不着急，慢慢悠悠逛逛还是不错的，比较推荐，推荐值☆☆
-曾厝垵
一直读不对这个字，都是叫：那个曾什么垵，愧对语文老师，这里到算是意外之喜，鼓浪屿回来已经挺累了，不过由于比较饿（什么原因后面说），并且离住的地方不远，就过去逛了逛，东西还蛮好吃的，芒果挺便宜，一大杯才十块，无骨鸡爪很贵，不是特别爱，臭豆腐不错的，也不算很贵，这里想起来，那边八婆婆的豆乳烧仙草还不错的，去中山路那会喝了，来曾厝垵也买了，奶茶爱好者可以试试，含糖量应该很高，不爱甜食或者减肥的同学慎重考虑好了再尝试，晚上那边从牌坊出来，沿着环岛路挺多夜宵店什么的，非常推荐，推荐值☆☆☆☆
-植物园
植物园还是挺名副其实的，有热带植物，沙漠多肉，因为赶时间逛得不多，热带雨林植物那太多人了，都是在那拍照，而且我指的拍照都是拍人照，本身就很小的路，各种十八线网红，或者普通游客在那摆 pose 拍照，挺无语的；沙漠多肉比较惊喜，好多比人高的仙人掌，一大片的仙人球，很可恶的是好多大仙人掌上都有人刻字，越来越体会到，我们社会人多了，什么样的都有，而且不少；还看了下百花厅，但没什么特别的，可能赶时间比较着急，没仔细看，比较推荐，推荐值☆☆☆
-灵玲马戏团
对这个其实比较排斥，主要是比较晚了，跑的有点远（我太懒了），一开始真的挺拉低体验感受的，上来个什么书法家，现场画马，卖画；不过后面的还算值回票价，主题是花木兰，空中动作应该很考验基本功，然后那些老外的飞轮还跳绳（不知道学名叫啥），动物那块不太忍心看，应该是吃了不少苦头，不过人都这样就往后点再心疼动物吧。
-总结
厦门是个非常适合干饭人的地方，吃饭的地方大部分是差不多一桌菜十个左右就完了，而且上来就一大碗饭，一瓶雪碧一瓶可乐，对于经常是家里跟亲戚吃饭都得十几二十个菜的乡下人来说，不太吃得惯这样的🤦♂️，当然很有可能是我们预算不足，点的差。但是有一点是我回杭州深有感触的，感觉杭州司机的素质真的是跟厦门的司机差了比较多，杭州除非公交车停了，否则人行道很难看到主动让人的，当然这里拿厦门这个旅游城市来对比也不是很公平，不过这也是体现城市现代化文明水平的一个维度吧。
+ 聊聊 mysql 索引的一些细节
+ /2020/12/27/%E8%81%8A%E8%81%8A-mysql-%E7%B4%A2%E5%BC%95%E7%9A%84%E4%B8%80%E4%BA%9B%E7%BB%86%E8%8A%82/
+ 前几天同事问了我个 mysql 索引的问题，虽然大概知道，但是还是想来实践下，就是 is null，is not null 这类查询是否能用索引，可能之前有些网上的文章说都是不能用索引，但是其实不是，我们来看个小试验
+CREATE TABLE `null_index_t` (
+ `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
+ `null_key` varchar(255) DEFAULT NULL,
+ `null_key1` varchar(255) DEFAULT NULL,
+ `null_key2` varchar(255) DEFAULT NULL,
+ PRIMARY KEY (`id`),
+ KEY `idx_1` (`null_key`) USING BTREE,
+ KEY `idx_2` (`null_key1`) USING BTREE,
+ KEY `idx_3` (`null_key2`) USING BTREE
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
+用个存储过程来插入数据
+
+delimiter $ #以delimiter来标记用$表示存储过程结束
+create procedure nullIndex1()
+begin
+declare i int;
+declare j int;
+set i=1;
+set j=1;
+while(i<=100) do
+ while(j<=100) do
+ IF (i % 3 = 0) THEN
+ INSERT INTO null_index_t ( `null_key`, `null_key1`, `null_key2` ) VALUES (null , LEFT(MD5(RAND()), 8), LEFT(MD5(RAND()), 8));
+ ELSEIF (i % 3 = 1) THEN
+ INSERT INTO null_index_t ( `null_key`, `null_key1`, `null_key2` ) VALUES (LEFT(MD5(RAND()), 8), NULL, LEFT(MD5(RAND()), 8));
+ ELSE
+ INSERT INTO null_index_t ( `null_key`, `null_key1`, `null_key2` ) VALUES (LEFT(MD5(RAND()), 8), LEFT(MD5(RAND()), 8), NULL);
+ END IF;
+ set j=j+1;
+ end while;
+ set i=i+1;
+ set j=1;
+end while;
+end
+$
+call nullIndex1();
+然后看下我们的 is null 查询
+EXPLAIN select * from null_index_t WHERE null_key is null;
+![]()
再来看看另一个
+EXPLAIN select * from null_index_t WHERE null_key is not null;
+![]()
从这里能看出来啥呢，可以思考下
+从上面可以发现，is null应该是用上了索引了，所以至少不是一刀切不能用，但是看着is not null好像不太行额
我们在做一点小改动，把这个表里的数据改成 9100 条是 null，剩下 900 条是有值的，然后再执行下
![]()
然后再来看看执行结果
+EXPLAIN select * from null_index_t WHERE null_key is null;
+![]()
+EXPLAIN select * from null_index_t WHERE null_key is not null;
+![]()
是不是不一样了，这里再补充下我试验使用的 mysql 是 5.7 的，不保证在其他版本的一致性，
其实可以看出随着数据量的变化，mysql 会不会使用索引是会变化的，不是说 is not null 一定会使用，也不是一定不会使用，而是优化器会根据查询成本做个预判，这个预判尽可能会减小查询成本，主要包括回表啥的，但是也不一定完全准确。
]]>
- 生活
- 旅游
+ C
+ Mysql
+ 索引
+ Mysql
- 生活
- 杭州
- 旅游
- 厦门
- 中山路
- 局口街
- 鼓浪屿
- 曾厝垵
- 植物园
- 马戏团
- 沙茶面
- 海蛎煎
+ mysql
+ 索引
+ is null
+ is not null
+ procedure
- 聊聊如何识别和意识到日常生活中的各类危险
- /2021/06/06/%E8%81%8A%E8%81%8A%E5%A6%82%E4%BD%95%E8%AF%86%E5%88%AB%E5%92%8C%E6%84%8F%E8%AF%86%E5%88%B0%E6%97%A5%E5%B8%B8%E7%94%9F%E6%B4%BB%E4%B8%AD%E7%9A%84%E5%90%84%E7%B1%BB%E5%8D%B1%E9%99%A9/
- 这篇博客的灵感又是来自于我从绍兴来杭州的路上，在我们进站以后上电梯快到的时候，突然前面不动了，右边我能看到的是有个人的行李箱一时拎不起来，另一边后面看到其实是个小孩子在那哭闹，一位妈妈就在那停着安抚或者可能有点手足无措，其实这一点应该是在几年前慢慢意识到是个非常危险的场景，特别是像绍兴北站这样上去站台是非常长的电梯，因为最近扩建改造，车次减少了很多，所以每一班都有很多人，检票上站台的电梯都是满员运转，试想这种情况，如果刚才那位妈妈再多停留一点时间，很可能就会出现后面的人上不来被挤下去，再严重点就是踩踏事件，但是这类情况很少人真的意识到，非常明显的例子就是很多人拿着比较大比较重的行李箱，不走垂梯，并且在快到的时候没有提前准备好，有可能在玩手机啥的，如果提不动，后面又是挤满人了，就很可能出现前面说的这种情况，并且其实这种是非紧急情况，大多数人都没有心理准备，一旦发生后果可能就会很严重，例如火灾地震疏散大部分人或者说负责引导的都是指示要有序撤离，防止踩踏，但是普通坐个扶梯，一般都不会有这个意识，但是如果这个时间比较长，出现了人员站不住往后倒了，真的会很严重。所以如果自己是带娃的或者带了很重的行李箱的，请提前做好准备，看到前面有人带的，最好也保持一定距离。
还有比如日常走路，旁边有车子停着的情况，比较基本的看车灯有没有亮着，亮着的是否是倒车灯，这种应该特别注意远离，至少保持距离，不能挨着走，很多人特别是一些老年人，在一些人比较多的路上，往往完全无视旁边这些车的状态，我走我的路，谁敢阻拦我，管他车在那动不动，其实真的非常危险，车子本身有视线死角，再加上司机的驾驶习惯和状态，想去送死跟碰瓷的除外，还有就是有一些车会比较特殊，车子发动着，但是没灯，可能是车子灯坏了或者司机通过什么方式关了灯，这种比较难避开，不过如果车子打着了，一般会有比较大的热量散发，车子刚灭了也会有，反正能远离点尽量远离，从轿车的车前面走过挨着走要比从屁股后面挨着走稍微安全一些，但也最好不要挨着车走。
最后一点其实是我觉得是我自己比较怕死，一般对来向的车或者从侧面出来的车会做更长的预判距离，特别是电瓶车，一般是不让人的，像送外卖的小哥，的确他们不太容易，但是真的很危险啊，基本就生死看刹车，能刹住就赚了，刹不住就看身子骨扛不扛撞了，只是这里要多说点又要谈到资本的趋利性了，总是想法设法的压榨以获取更多的利益，也不扯远了，能远离就远离吧。
+ 聊聊Java中的单例模式
+ /2019/12/21/%E8%81%8A%E8%81%8AJava%E4%B8%AD%E7%9A%84%E5%8D%95%E4%BE%8B%E6%A8%A1%E5%BC%8F/
+ 这是个 Java 面试的高频问题，我也遇到过，以往都是觉得这类题没意思，网上一搜一大堆，也不愿意记，其实说回来，主要还是没静下心来好好去理解，今天无意中看到一个课程，基本帮我把一些疑惑的点讲清楚了，首先单例是啥意思，这个其实是有范围一说，比如我起了个Spring Boot应用，在这个应用范围内，我的常规 bean 是单例的，意味着 getBean 的时候其实永远只会拿到那一个对象，那要怎么来写一个单例呢，首先就是传说中的饿汉模式，也是最简单的
+饿汉模式
public class Singleton1 {
+ // 首先，将构造方法变成私有的
+ private Singleton1() {};
+ // 创建私有静态实例，这样第一次使用的时候就会进行创建
+ private static Singleton instance = new Singleton1();
+
+ // 使用这个对象都是通过这个 getInstance 来获取
+ public static Singleton1 getInstance() {
+ return instance;
+ }
+ // 瞎写一个静态方法。这里想说的是，如果我们只是要调用 Singleton.getDate(...)，
+ // 本来是不想要生成 Singleton 实例的，不过没办法，已经生成了
+ public static Date getDate(String mode) {return new Date();}
+}
+上面借鉴了一些代码，其实这是最基本，也不会错的方法，但是正如其中getDate方法里说的问题，有时候并没有想那这个对象，但是因为我调用了这个类的静态方法，导致对象已经生成了，可能这也是饿汉模式名字的来由，不管三七二十一给你生成个单例就完事了，不管有没有用，但是这种个人觉得也没啥大问题，如果是面试的话最好说出来它的缺点
+饱汉模式
public class Singleton2 {
+ // 首先，也是先堵死 new Singleton() 这条路,将构造方法变成私有
+ private Singleton2() {}
+ // 和饿汉模式相比，这边不需要先实例化出来，注意这里的 volatile，它是必须的
+ private static volatile Singleton2 instance = null;
+
+ private int m = 9;
+
+ public static Singleton getInstance() {
+ if (instance == null) {
+ // 加锁
+ synchronized (Singleton2.class) {
+ // 这一次判断也是必须的，不然会有并发问题
+ if (instance == null) {
+ instance = new Singleton2();
+ }
+ }
+ }
+ return instance;
+ }
+}
+这里容易错的有三点，理解了其实就比较好记了
+第一点，为啥不在 getInstance 上整个代码块加 synchronized，这个其实比较容易理解，就是锁的力度太大，性能太差了，这点其实也要去理解，可以举个夸张的例子，比如我一个电商的服务，如果为了避免一个人的订单出现问题，是不是可以从请求入口就把他锁住，到请求结束释放，那么里面做的事情都有保障，然而这显然不可能，因为我们想要这种竞态条件抢占资源的时间尽量减少，防止其他线程等待。
第二点，为啥synchronized之已经检查了 instance == null,还要在里面再检查一次，这个有个术语，叫 double check lock,但是为啥要这么做呢，其实很简单，想象当有两个线程，都过了第一步为空判断，这个时候只有一个线程能拿到这个锁，另一个线程就等待了，如果不再判断一次，那么第一个线程新建完对象释放锁之后，第二个线程又能拿到锁，再去创建一个对象。
第三点，为啥要volatile关键字，原先对它的理解是它修饰的变量在 JMM 中能及时将变量值写到主存中，但是它还有个很重要的作用，就是防止指令重排序，instance = new Singleton();这行代码其实在底层是分成三条指令执行的，第一条是在堆上申请了一块内存放这个对象，但是对象的字段啥的都还是默认值，第二条是设置对象的值，比如上面的 m 是 9，然后第三条是将这个对象和虚拟机栈上的指针建立引用关联，那么如果我不用volatile关键字，这三条指令就有可能出现重排，比如变成了 1-3-2 这种顺序，当执行完第二步时，有个线程来访问这个对象了，先判断是不是空，发现不是空的，就拿去直接用了，是不是就出现问题了，所以这个volatile也是不可缺少的
+嵌套类
public class Singleton3 {
+
+ private Singleton3() {}
+ // 主要是使用了 嵌套类可以访问外部类的静态属性和静态方法 的特性
+ private static class Holder {
+ private static Singleton3 instance = new Singleton3();
+ }
+ public static Singleton3 getInstance() {
+ return Holder.instance;
+ }
+}
+这个我个人感觉是饿汉模式的升级版，可以在调用getInstance的时候去实例化对象，也是比较推荐的
+枚举单例
public enum Singleton {
+ INSTANCE;
+
+ public void doSomething(){
+ //todo doSomething
+ }
+}
+枚举很特殊，它在类加载的时候会初始化里面的所有的实例，而且 JVM 保证了它们不会再被实例化，所以它天生就是单例的。
]]>
- 生活
+ Java
+ Design Patterns
+ Singleton
- 生活
- 糟心事
- 扶梯
- 踩踏
- 安全
- 电瓶车
+ 设计模式
+ Design Patterns
+ 单例
+ Singleton
@@ -13784,35 +13411,260 @@ function hiicu64() {
SpringBoot
- Java
- Spring
- SpringBoot
- 自动装配
- AutoConfiguration
+ Java
+ Spring
+ SpringBoot
+ 自动装配
+ AutoConfiguration
+
+
+
+ 聊聊一次 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/
+ 熟悉我的人（谁熟悉你啊🙄）知道我以前写过 PHP，虽然现在在工作中没用到了，但是自己的一些小工具还是会用 PHP 来写，但是在 Mac 碰到了一个环境相关的问题，因为我也是个更新狂魔，用了 brew 之后因为 gfw 的原因，如果长时间不更新，有时候要装一个用它装一个软件的话，前置的更新耗时就会让人非常头大，所以我基本会隔天 update 一下，但是这样会带来一个很心烦的问题，就是像这样，因为我是要用一个固定版本的 PHP，如果一直升需要一直配扩展啥的也很麻烦，如果一直升级 PHP 到最新版可能会比较少碰到这个问题
+dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.64.dylib
+这是什么鬼啊，然后我去这个目录下看了下，已经都是libicui18n.67.dylib了，而且它没有把原来的版本保留下来，首先这个是个叫 icu4c是啥玩意，谷歌了一下
+
+ICU4C是ICU在C/C++平台下的版本, ICU(International Component for Unicode)是基于”IBM公共许可证”的，与开源组织合作研究的, 用于支持软件国际化的开源项目。ICU4C提供了C/C++平台强大的国际化开发能力，软件开发者几乎可以使用ICU4C解决任何国际化的问题，根据各地的风俗和语言习惯，实现对数字、货币、时间、日期、和消息的格式化、解析，对字符串进行大小写转换、整理、搜索和排序等功能，必须一提的是，ICU4C提供了强大的BIDI算法，对阿拉伯语等BIDI语言提供了完善的支持。
+
+然后首先想到的解决方案就是能不能我使用brew install icu4c@64来重装下原来的版本，发现不行，并木有，之前的做法就只能是去网上把 64 的下载下来，然后放到这个目录，比较麻烦不智能，虽然没抱着希望在谷歌着，不过这次竟然给我找到了一个我认为非常 nice 的解决方案，因为是在 Stack Overflow 找到的，本着写给像我这样的小小白看的，那就稍微翻译一下
第一步，我们到 brew的目录下
+cd $(brew --prefix)/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
+这个可以理解为是 maven 的 pom 文件，不过有很多不同之处，使用ruby 写的，然后一个文件对应一个组件或者软件，那我们看下有个叫icu4c.rb的文件，
第二步看看它的提交历史
+git log --follow icu4c.rb
+在 git log 的海洋中寻找，寻找它的(64版本)的身影
![]()
第三步注意这三个红框，Stack Overflow 给出来的答案这一步是找到这个 commit id 直接切出一个新分支
+git checkout -b icu4c-63 e7f0f10dc63b1dc1061d475f1a61d01b70ef2cb7
+其实注意 commit id 旁边的红框，这个是有tag 的，可以直接
+git checkout icu4c-64
+PS: 因为我的问题是出在 64 的问题，Stack Overflow 回答的是 63 的，反正是一样的解决方法
第四部，切回去之后我们就可以用 brew 提供的基于文件的安装命令来重新装上 64 版本
+brew reinstall ./icu4c.rb
+然后就是第五步，切换版本
+brew switch icu4c 64.2
+最后把分支切回来
+git checkout master
+是不是感觉很厉害的解决方法，大佬还提供了一个更牛的，直接写个 zsh 方法
+# zsh
+function hiicu64() {
+ local last_dir=$(pwd)
+
+ cd $(brew --prefix)/Homebrew/Library/Taps/homebrew/homebrew-core/Formula
+ git checkout icu4c-4
+ brew reinstall ./icu4c.rb
+ brew switch icu4c 64.2
+ git checkout master
+
+ cd $last_dir
+}
+对应自己的版本改改版本号就可以了，非常好用。
+]]>
+
+ Mac
+ PHP
+ Homebrew
+ icu4c
+
+
+ Mac
+ PHP
+ Homebrew
+ icu4c
+ zsh
+
+
+
+ 聊聊 redis 缓存的应用问题
+ /2021/01/31/%E8%81%8A%E8%81%8A-redis-%E7%BC%93%E5%AD%98%E7%9A%84%E5%BA%94%E7%94%A8%E9%97%AE%E9%A2%98/
+ 前面写过一系列的 redis 源码分析的，但是实际上很多的问题还是需要结合实际的使用，然后其实就避不开缓存使用的三个著名问题，穿透，击穿和雪崩，这三个概念也是有着千丝万缕的关系，
+缓存穿透
缓存穿透是指当数据库中本身就不存在这个数据的时候，使用一般的缓存策略时访问不到缓存后就访问数据库，但是因为数据库也没数据，所以如果不做任何策略优化的话，这类数据就每次都会访问一次数据库，对数据库压力也会比较大。
+缓存击穿
缓存击穿跟穿透比较类似的，都是访问缓存不在，然后去访问数据库，与穿透不一样的是击穿是在数据库中存在数据，但是可能由于第一次访问，或者缓存过期了，需要访问到数据库，这对于访问量小的情况其实算是个正常情况，但是随着请求量变高就会引发一些性能隐患。
+缓存雪崩
缓存雪崩就是击穿的大规模集群效应，当大量的缓存过期失效的时候，这些请求都是直接访问到数据库了，会对数据库造成很大的压力。
+对于以上三种场景也有一些比较常见的解决方案，但也不能说是万无一失的，需要随着业务去寻找合适的方案
+解决缓存穿透
对于数据库中就没这个数据的时候，一种是可以对这个 key 设置下空值，即以一个特定的表示是数据库不存在的，这种情况需要合理地调整过期时间，当这个 key 在数据库中有数据了的话，也需要有策略去更新这个值，并且如果这类 key 非常多，这个方法就会不太合适，就可以使用第二种方法，就是布隆过滤器，bloom filter，前置一个布隆过滤器，当这个 key 在数据库不存在的话，先用布隆过滤器挡一道，如果不在的话就直接返回了，当然布隆过滤器不是绝对的准确的
+解决缓存击穿
当一个 key 的缓存过期了，如果大量请求过来访问这个 key，请求都会落在数据库里，这个时候就可以使用一些类似于互斥锁的方式去让一个线程去访问数据库，更新缓存，但是这里其实也有个问题，就是如果是热点 key 其实这种方式也比较危险，万一更新失败，或者更新操作的时候耗时比较久，就会有一大堆请求卡在那，这种情况可能需要有一些异步提前刷新缓存，可以结合具体场景选择方式
+解决缓存雪崩
雪崩的情况是指大批量的 key 都一起过期了，击穿的放大版，大批量的请求都打到数据库上了，一方面有可能直接缓存不可用了，就需要用集群化高可用的缓存服务，然后对于实际使用中也可以使用本地缓存结合 redis 缓存，去提高可用性，再配合一些限流措施，然后就是缓存使用过程总的过期时间最好能加一些随机值，防止在同一时间过期而导致雪崩，结合互斥锁防止大量请求打到数据库。
+]]>
+
+ Redis
+ 应用
+ 缓存
+ 缓存
+ 穿透
+ 击穿
+ 雪崩
+
+
+ Redis
+ 缓存穿透
+ 缓存击穿
+ 缓存雪崩
+ 布隆过滤器
+ bloom filter
+ 互斥锁
+
+
+
+ 聊聊传说中的 ThreadLocal
+ /2021/05/30/%E8%81%8A%E8%81%8A%E4%BC%A0%E8%AF%B4%E4%B8%AD%E7%9A%84-ThreadLocal/
+ 说来也惭愧，这个 ThreadLocal 其实一直都是一知半解，而且看了一下之后还发现记错了，所以还是记录下
原先记忆里的都是反过来，一个 ThreadLocal 是里面按照 thread 作为 key，存储线程内容的，真的是半解都米有，完全是错的，这样就得用 concurrentHashMap 这种去存储并且要锁定线程了，然后内容也只能存一个了，想想简直智障
+究竟是啥结构
比如我们在代码中 new 一个 ThreadLocal，
+public static void main(String[] args) {
+ ThreadLocal<Man> tl = new ThreadLocal<>();
+
+ new Thread(() -> {
+ try {
+ TimeUnit.SECONDS.sleep(2);
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ System.out.println(tl.get());
+ }).start();
+ new Thread(() -> {
+ try {
+ TimeUnit.SECONDS.sleep(1);
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ tl.set(new Man());
+ }).start();
+ }
+
+ static class Man {
+ String name = "nick";
+ }
+这里构造了两个线程，一个先往里设值，一个后从里取，运行看下结果，
![]()
知道这个用法的话肯定知道是取不到值的，只是具体的原理原来搞错了，我们来看下设值 set 方法
+public void set(T value) {
+ Thread t = Thread.currentThread();
+ ThreadLocalMap map = getMap(t);
+ if (map != null)
+ map.set(this, value);
+ else
+ createMap(t, value);
+}
+写博客这会我才明白我原来咋会错得这么离谱，看到第一行代码 t 就是当前线程，然后第二行就是用这个线程去getMap，然后我是把这个当成从 map 里取值了，其实这里是
+ThreadLocalMap getMap(Thread t) {
+ return t.threadLocals;
+}
+获取 t 的 threadLocals 成员变量，那这个 threadLocals 又是啥呢
![]()
它其实是线程 Thread 中的一个类型是java.lang.ThreadLocal.ThreadLocalMap的成员变量
这是 ThreadLocal 的一个静态成员变量
+static class ThreadLocalMap {
+
+ /**
+ * The entries in this hash map extend WeakReference, using
+ * its main ref field as the key (which is always a
+ * ThreadLocal object). Note that null keys (i.e. entry.get()
+ * == null) mean that the key is no longer referenced, so the
+ * entry can be expunged from table. Such entries are referred to
+ * as "stale entries" in the code that follows.
+ */
+ static class Entry extends WeakReference<ThreadLocal<?>> {
+ /** The value associated with this ThreadLocal. */
+ Object value;
+
+ Entry(ThreadLocal<?> k, Object v) {
+ super(k);
+ value = v;
+ }
+ }
+ }
+全部代码有点长，只截取了一小部分，然后我们再回头来分析前面说的 set 过程，再 copy 下代码
+public void set(T value) {
+ Thread t = Thread.currentThread();
+ ThreadLocalMap map = getMap(t);
+ if (map != null)
+ map.set(this, value);
+ else
+ createMap(t, value);
+}
+获取到 map 以后呢，如果 map 不为空，就往 map 里 set，这里注意 key 是啥，其实是当前这个 ThreadLocal，这里就比较明白了究竟是啥结构，每个线程都会维护自身的 ThreadLocalMap，它是线程的一个成员变量，当创建 ThreadLocal 的时候，进行设值的时候其实是往这个 map 里以 ThreadLocal 作为 key，往里设 value。
+内存泄漏是什么鬼
这里又要看下前面的 ThreadLocalMap 结构了，类似 HashMap，它有个 Entry 结构，在设置的时候会先包装成一个 Entry
+private void set(ThreadLocal<?> key, Object value) {
+
+ // We don't use a fast path as with get() because it is at
+ // least as common to use set() to create new entries as
+ // it is to replace existing ones, in which case, a fast
+ // path would fail more often than not.
+
+ Entry[] tab = table;
+ int len = tab.length;
+ int i = key.threadLocalHashCode & (len-1);
+
+ for (Entry e = tab[i];
+ e != null;
+ e = tab[i = nextIndex(i, len)]) {
+ ThreadLocal<?> k = e.get();
+
+ if (k == key) {
+ e.value = value;
+ return;
+ }
+
+ if (k == null) {
+ replaceStaleEntry(key, value, i);
+ return;
+ }
+ }
+
+ tab[i] = new Entry(key, value);
+ int sz = ++size;
+ if (!cleanSomeSlots(i, sz) && sz >= threshold)
+ rehash();
+}
+这里其实比较重要的就是前面的 Entry 的构造方法，Entry 是个 WeakReference 的子类，然后在构造方法里可以看到 key 会被包装成一个弱引用，这里为什么使用弱引用，其实是方便这个 key 被回收，如果前面的 ThreadLocal tl实例被设置成 null 了，如果这里是直接的强引用的话，就只能等到线程整个回收了，但是其实是弱引用也会有问题，主要是因为这个 value，如果在 ThreadLocal tl 被设置成 null 了，那么其实这个 value 就会没法被访问到，所以最好的操作还是在使用完了就 remove 掉
+]]>
+
+ Java
+
+
+ Java
+ ThreadLocal
+ 弱引用
+ 内存泄漏
+ WeakReference
+
+
+
+ 聊聊厦门旅游的好与不好
+ /2021/04/11/%E8%81%8A%E8%81%8A%E5%8E%A6%E9%97%A8%E6%97%85%E6%B8%B8%E7%9A%84%E5%A5%BD%E4%B8%8E%E4%B8%8D%E5%A5%BD/
+ 这几天去了趟厦门，原来几年前就想去了，本来都请好假了，后面因为一些事情没去成，这次刚好公司组织，就跟 LD 一起去了厦门，也不洋洋洒洒地写游记了，后面可能会有，今天先来总结下好的地方和比较坑的地方。
这次主要去了中山路、鼓浪屿、曾厝(cuo)垵、植物园、灵玲马戏团，因为住的离环岛路比较近，还有幸现场看了下厦门马拉松，其中
+中山路
这里看上去是有点民国时期的建筑风格，部分像那种电视里的租界啥的，不过这次去的时候都在翻修，路一大半拦起来了，听导游说这里往里面走有个局口街，然后上次听前同事说厦门比较有名的就是沙茶面和海蛎煎，不出意料的不太爱吃，沙茶面比较普通，可能是没吃到正宗的，海蛎煎吃不惯，倒是有个大叔的沙茶里脊还不错，在局口街那，还有小哥在那拍，应该也算是个网红打卡点了，然后吃了个油条麻糍也还不错，总体如果是看建筑的话可能最近不是个好时间，个人也没这方面爱好，吃的话最好多打听打听沙茶面跟海蛎煎哪里正宗。如果不知道哪家好吃，也不爱看这类建筑的可以排个坑。
+鼓浪屿
鼓浪屿也是完全没啥概念，需要乘船过去，但是只要二十分钟，岛上没有机动车，基本都靠走，有几个比较有名的地方，菽庄花园，里面有钢琴博物馆，对这个感兴趣的可以去看看，旁边是沙滩还可以逛逛，然后有各种博物馆，风琴啥的，岛上最大的特色是巷子多，道听途说有三百多条小巷，还有几个网红打卡点，周杰伦晴天墙，还有个最美转角，都是挤满了人排队打卡拍照，不过如果不着急，慢慢悠悠逛逛还是不错的，比较推荐，推荐值☆☆
+曾厝垵
一直读不对这个字，都是叫：那个曾什么垵，愧对语文老师，这里到算是意外之喜，鼓浪屿回来已经挺累了，不过由于比较饿（什么原因后面说），并且离住的地方不远，就过去逛了逛，东西还蛮好吃的，芒果挺便宜，一大杯才十块，无骨鸡爪很贵，不是特别爱，臭豆腐不错的，也不算很贵，这里想起来，那边八婆婆的豆乳烧仙草还不错的，去中山路那会喝了，来曾厝垵也买了，奶茶爱好者可以试试，含糖量应该很高，不爱甜食或者减肥的同学慎重考虑好了再尝试，晚上那边从牌坊出来，沿着环岛路挺多夜宵店什么的，非常推荐，推荐值☆☆☆☆
+植物园
植物园还是挺名副其实的，有热带植物，沙漠多肉，因为赶时间逛得不多，热带雨林植物那太多人了，都是在那拍照，而且我指的拍照都是拍人照，本身就很小的路，各种十八线网红，或者普通游客在那摆 pose 拍照，挺无语的；沙漠多肉比较惊喜，好多比人高的仙人掌，一大片的仙人球，很可恶的是好多大仙人掌上都有人刻字，越来越体会到，我们社会人多了，什么样的都有，而且不少；还看了下百花厅，但没什么特别的，可能赶时间比较着急，没仔细看，比较推荐，推荐值☆☆☆
+灵玲马戏团
对这个其实比较排斥，主要是比较晚了，跑的有点远（我太懒了），一开始真的挺拉低体验感受的，上来个什么书法家，现场画马，卖画；不过后面的还算值回票价，主题是花木兰，空中动作应该很考验基本功，然后那些老外的飞轮还跳绳（不知道学名叫啥），动物那块不太忍心看，应该是吃了不少苦头，不过人都这样就往后点再心疼动物吧。
+总结
厦门是个非常适合干饭人的地方，吃饭的地方大部分是差不多一桌菜十个左右就完了，而且上来就一大碗饭，一瓶雪碧一瓶可乐，对于经常是家里跟亲戚吃饭都得十几二十个菜的乡下人来说，不太吃得惯这样的🤦♂️，当然很有可能是我们预算不足，点的差。但是有一点是我回杭州深有感触的，感觉杭州司机的素质真的是跟厦门的司机差了比较多，杭州除非公交车停了，否则人行道很难看到主动让人的，当然这里拿厦门这个旅游城市来对比也不是很公平，不过这也是体现城市现代化文明水平的一个维度吧。
+]]>
+
+ 生活
+ 旅游
+
+
+ 生活
+ 杭州
+ 旅游
+ 厦门
+ 中山路
+ 局口街
+ 鼓浪屿
+ 曾厝垵
+ 植物园
+ 马戏团
+ 沙茶面
+ 海蛎煎
- 聊聊我刚学会的应用诊断方法
- /2020/05/22/%E8%81%8A%E8%81%8A%E6%88%91%E5%88%9A%E5%AD%A6%E4%BC%9A%E7%9A%84%E5%BA%94%E7%94%A8%E8%AF%8A%E6%96%AD%E6%96%B9%E6%B3%95/
- 因为传说中的出身问题，我以前写的是PHP，在使用 swoole 之前，基本的应用调试手段就是简单粗暴的 var_dump，exit，对于单进程模型的 PHP 也是简单有效，技术栈换成 Java 之后，就变得没那么容易，一方面是需要编译，另一方面是一般都是基于 spring 的项目，如果问题定位比较模糊，那框架层的是很难靠简单的 System.out.println 或者打 log 解决，(PS：我觉得可能我写的东西比较适合从 PHP 这种弱类型语言转到 Java 的小白同学)这个时候一方面因为是 Java，有了非常好用的 idea IDE 的支持，可以各种花式调试，条件断点尤其牛叉，但是又因为有 Spring+Java 的双重原因，有些情况下单步调试可以把手按废掉，这也是我之前一直比较困惑苦逼的点，后来随着慢慢精（jiang）进（you）之后，比如对于一个 oom 的情况，我们可以通过启动参数加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=xx/xx 来配置溢出时的堆dump 日志，获取到这个文件后，我们可以通过像 Memory Analyzer (MAT)[https://www.eclipse.org/mat/] (The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption.)来查看诊断问题所在，之前用到的时候是因为有个死循环一直往链表里塞数据，属于比较简单的，后来一次是由于运维进行应用迁移时按默认的统一配置了堆内存大小，导致内存的确不够用，所以溢出了，
今天想说的其实主要是我们的 thread dump，这也是我最近才真正用的一个方法，可能真的很小白了，用过 ide 的单步调试其实都知道会有一个一层层的玩意，比如函数从 A，调用了 B，再从 B 调用了 C，一直往下(因为是 Java，所以还有很多🤦♂️)，这个其实也是大部分语言的调用模型，利用了栈这个数据结构，通过这个结构我们可以知道代码的调用链路，由于对于一个 spring 应用，在本身框架代码量非常庞大的情况下，外加如果应用代码也是非常多的时候，有时候通过单步调试真的很难短时间定位到问题，需要非常大的耐心和仔细观察，当然不是说完全不行，举个例子当我的应用经常启动需要非常长的时间，因为本身应用有非常多个 bean，比较难说究竟是 bean 的加载的确很慢还是有什么异常原因，这种时候就可以使用 thread dump 了，具体怎么操作呢
![]()
如果在idea 中运行或者调试时，可以直接点击这个照相机一样的按钮，右边就会出现了左边会显示所有的线程，右边会显示线程栈，
-"main@1" prio=5 tid=0x1 nid=NA runnable
- java.lang.Thread.State: RUNNABLE
- at TreeDistance.treeDist(TreeDistance.java:64)
- at TreeDistance.treeDist(TreeDistance.java:65)
- at TreeDistance.treeDist(TreeDistance.java:65)
- at TreeDistance.treeDist(TreeDistance.java:65)
- at TreeDistance.main(TreeDistance.java:45)
-这就是我们主线程的堆栈信息了，main 表示这个线程名，prio表示优先级，默认是 5，tid 表示线程 id，nid 表示对应的系统线程，后面的runnable 表示目前线程状态，因为是被我打了断点，所以是就许状态，然后下面就是对应的线程栈内容了，在TreeDistance类的 treeDist方法中，对应的文件行数是 64 行。
这里使用 thread dump一般也不会是上面我截图代码里的这种代码量很少的，一般是大型项目，有时候跑着跑着没反应，又不知道跑到哪了，特别是一些刚接触的大项目或者需要定位一个大项目的一个疑难问题，一时没思路时，可以使用这个方法，个人觉得非常有帮助。
+ 聊聊如何识别和意识到日常生活中的各类危险
+ /2021/06/06/%E8%81%8A%E8%81%8A%E5%A6%82%E4%BD%95%E8%AF%86%E5%88%AB%E5%92%8C%E6%84%8F%E8%AF%86%E5%88%B0%E6%97%A5%E5%B8%B8%E7%94%9F%E6%B4%BB%E4%B8%AD%E7%9A%84%E5%90%84%E7%B1%BB%E5%8D%B1%E9%99%A9/
+ 这篇博客的灵感又是来自于我从绍兴来杭州的路上，在我们进站以后上电梯快到的时候，突然前面不动了，右边我能看到的是有个人的行李箱一时拎不起来，另一边后面看到其实是个小孩子在那哭闹，一位妈妈就在那停着安抚或者可能有点手足无措，其实这一点应该是在几年前慢慢意识到是个非常危险的场景，特别是像绍兴北站这样上去站台是非常长的电梯，因为最近扩建改造，车次减少了很多，所以每一班都有很多人，检票上站台的电梯都是满员运转，试想这种情况，如果刚才那位妈妈再多停留一点时间，很可能就会出现后面的人上不来被挤下去，再严重点就是踩踏事件，但是这类情况很少人真的意识到，非常明显的例子就是很多人拿着比较大比较重的行李箱，不走垂梯，并且在快到的时候没有提前准备好，有可能在玩手机啥的，如果提不动，后面又是挤满人了，就很可能出现前面说的这种情况，并且其实这种是非紧急情况，大多数人都没有心理准备，一旦发生后果可能就会很严重，例如火灾地震疏散大部分人或者说负责引导的都是指示要有序撤离，防止踩踏，但是普通坐个扶梯，一般都不会有这个意识，但是如果这个时间比较长，出现了人员站不住往后倒了，真的会很严重。所以如果自己是带娃的或者带了很重的行李箱的，请提前做好准备，看到前面有人带的，最好也保持一定距离。
还有比如日常走路，旁边有车子停着的情况，比较基本的看车灯有没有亮着，亮着的是否是倒车灯，这种应该特别注意远离，至少保持距离，不能挨着走，很多人特别是一些老年人，在一些人比较多的路上，往往完全无视旁边这些车的状态，我走我的路，谁敢阻拦我，管他车在那动不动，其实真的非常危险，车子本身有视线死角，再加上司机的驾驶习惯和状态，想去送死跟碰瓷的除外，还有就是有一些车会比较特殊，车子发动着，但是没灯，可能是车子灯坏了或者司机通过什么方式关了灯，这种比较难避开，不过如果车子打着了，一般会有比较大的热量散发，车子刚灭了也会有，反正能远离点尽量远离，从轿车的车前面走过挨着走要比从屁股后面挨着走稍微安全一些，但也最好不要挨着车走。
最后一点其实是我觉得是我自己比较怕死，一般对来向的车或者从侧面出来的车会做更长的预判距离，特别是电瓶车，一般是不让人的，像送外卖的小哥，的确他们不太容易，但是真的很危险啊，基本就生死看刹车，能刹住就赚了，刹不住就看身子骨扛不扛撞了，只是这里要多说点又要谈到资本的趋利性了，总是想法设法的压榨以获取更多的利益，也不扯远了，能远离就远离吧。
]]>
- Java
- Thread dump
- 问题排查
- 工具
+ 生活
- Java
- Thread dump
+ 生活
+ 糟心事
+ 扶梯
+ 踩踏
+ 安全
+ 电瓶车
@@ -13859,6 +13711,30 @@ function hiicu64() {
3PC
+
+ 聊聊我刚学会的应用诊断方法
+ /2020/05/22/%E8%81%8A%E8%81%8A%E6%88%91%E5%88%9A%E5%AD%A6%E4%BC%9A%E7%9A%84%E5%BA%94%E7%94%A8%E8%AF%8A%E6%96%AD%E6%96%B9%E6%B3%95/
+ 因为传说中的出身问题，我以前写的是PHP，在使用 swoole 之前，基本的应用调试手段就是简单粗暴的 var_dump，exit，对于单进程模型的 PHP 也是简单有效，技术栈换成 Java 之后，就变得没那么容易，一方面是需要编译，另一方面是一般都是基于 spring 的项目，如果问题定位比较模糊，那框架层的是很难靠简单的 System.out.println 或者打 log 解决，(PS：我觉得可能我写的东西比较适合从 PHP 这种弱类型语言转到 Java 的小白同学)这个时候一方面因为是 Java，有了非常好用的 idea IDE 的支持，可以各种花式调试，条件断点尤其牛叉，但是又因为有 Spring+Java 的双重原因，有些情况下单步调试可以把手按废掉，这也是我之前一直比较困惑苦逼的点，后来随着慢慢精（jiang）进（you）之后，比如对于一个 oom 的情况，我们可以通过启动参数加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=xx/xx 来配置溢出时的堆dump 日志，获取到这个文件后，我们可以通过像 Memory Analyzer (MAT)[https://www.eclipse.org/mat/] (The Eclipse Memory Analyzer is a fast and feature-rich Java heap analyzer that helps you find memory leaks and reduce memory consumption.)来查看诊断问题所在，之前用到的时候是因为有个死循环一直往链表里塞数据，属于比较简单的，后来一次是由于运维进行应用迁移时按默认的统一配置了堆内存大小，导致内存的确不够用，所以溢出了，
今天想说的其实主要是我们的 thread dump，这也是我最近才真正用的一个方法，可能真的很小白了，用过 ide 的单步调试其实都知道会有一个一层层的玩意，比如函数从 A，调用了 B，再从 B 调用了 C，一直往下(因为是 Java，所以还有很多🤦♂️)，这个其实也是大部分语言的调用模型，利用了栈这个数据结构，通过这个结构我们可以知道代码的调用链路，由于对于一个 spring 应用，在本身框架代码量非常庞大的情况下，外加如果应用代码也是非常多的时候，有时候通过单步调试真的很难短时间定位到问题，需要非常大的耐心和仔细观察，当然不是说完全不行，举个例子当我的应用经常启动需要非常长的时间，因为本身应用有非常多个 bean，比较难说究竟是 bean 的加载的确很慢还是有什么异常原因，这种时候就可以使用 thread dump 了，具体怎么操作呢
![]()
如果在idea 中运行或者调试时，可以直接点击这个照相机一样的按钮，右边就会出现了左边会显示所有的线程，右边会显示线程栈，
+"main@1" prio=5 tid=0x1 nid=NA runnable
+ java.lang.Thread.State: RUNNABLE
+ at TreeDistance.treeDist(TreeDistance.java:64)
+ at TreeDistance.treeDist(TreeDistance.java:65)
+ at TreeDistance.treeDist(TreeDistance.java:65)
+ at TreeDistance.treeDist(TreeDistance.java:65)
+ at TreeDistance.main(TreeDistance.java:45)
+这就是我们主线程的堆栈信息了，main 表示这个线程名，prio表示优先级，默认是 5，tid 表示线程 id，nid 表示对应的系统线程，后面的runnable 表示目前线程状态，因为是被我打了断点，所以是就许状态，然后下面就是对应的线程栈内容了，在TreeDistance类的 treeDist方法中，对应的文件行数是 64 行。
这里使用 thread dump一般也不会是上面我截图代码里的这种代码量很少的，一般是大型项目，有时候跑着跑着没反应，又不知道跑到哪了，特别是一些刚接触的大项目或者需要定位一个大项目的一个疑难问题，一时没思路时，可以使用这个方法，个人觉得非常有帮助。
+]]>
+
+ Java
+ Thread dump
+ 问题排查
+ 工具
+
+
+ Java
+ Thread dump
+
+
聊聊最近平淡的生活之又聊通勤
/2021/11/07/%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/
@@ -13927,22 +13803,6 @@ 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/01/17/%E8%81%8A%E8%81%8A%E9%82%A3%E4%BA%9B%E5%8A%A0%E5%A1%9E%E7%8B%97/
@@ -13961,17 +13821,19 @@ 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，估计在交管局那边我就懵逼了，各种插队，而且车子开着车子，也不能随便跑，所以建议办这个的时候有个人一起比较好。
]]>
生活
生活
- 看剧
+ 换车牌
@@ -13989,22 +13851,17 @@ function hiicu64() {
- 这周末我又在老丈人家打了天小工
- /2020/08/30/%E8%BF%99%E5%91%A8%E6%9C%AB%E6%88%91%E5%8F%88%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 俩人晚起了一点，我真的是只要有事，早上就醒的很早，准备八点出发的，六点就醒了，然后想继续睡就一直做梦🤦♂️，差不多八点半多到的丈人家，他们应该已经干了有一会了，我们到了以后就分配给我撬地板的活，上次说的那个敲掉柜子的房间里，还铺着质地还不错的木地板，但是也不想要了，得撬掉重新铺。
拿着撬棍和榔头就上楼去干了，浙江这几天的天气，最高温度一般 38、9，楼上那个房间也没风扇，有了也不能用，都是灰尘，撬了两下，我感觉我体内的水就像真气爆发一样变成汗炸了出来，眼睛全被汗糊住了，可能大部分人不太了解地板是怎么铺的，一般是在地面先铺一层混凝土，混凝土中间嵌进去规则的长条木条，然后真正的地板一块块的都是钉在那个木条上，用那种气枪钉和普通的钉子，并且块跟块之前还有一个木头的槽结构相互耦合，然后边缘的一圈在用较薄的木板将整个木地板封边(这些词都是我现造的)，边缘的用的钉子会更多，所以那几下真的很用力，而且撬地板，得蹲下起来，如此反复，对于我这个体重快超过身高的中年人来说的确是非常大的挑战，接下来继续撬了几个，已经有种要虚脱晕倒的感觉了，及时去喝水擦了汗，又歇了一会，为啥一上来就这么拼呢，主要是因为那个房间丈人在干活的时候是直接看得到的🤦♂️，后来被 LD 一顿教育，本来就是去帮忙的，又不是专业做这个的，急啥。
喝了水之后，又稍稍歇了一会，就开始继续撬了，本来觉得这个地板撬着好像还行，房间不大，没多久就撬完了，撬完之后喝了点饮料(补充点糖分，早餐吃得少，有点低血糖)，然后看到 LD 在撬下面的木条了，这个动作开始了那天最大的经验值收集行动，前面说了这个木条一般是跟混凝土一块铺上去的，但是谁也没想到，这个混凝土铺上去的时候竟然处理的这么随意，根本没考虑跟下面的贴合，所以撬木条的时候直接把木条跟木条中间大块大块的混凝土一块撬起来了，想想那重量，于是我这靠蛮力干活的，就用力把木条带着混凝土一块撬了起来，还沾沾自喜，但是发现结果是撬起来一块之后，体力值瞬间归零，上一篇我也提到了，其实干这类活也是很有技巧性的，但是上次的是我没学会，可能需要花时间学的，但是这次是LD 用她的纤细胳膊教会我的，我在撬的时候，屏住一口气，双手用力，起，大概是吃好几口奶的力气都用出来了，但是 LD 在我休息的时候，慢慢悠悠的，先把撬棍挤到木条或者混凝土跟下层的缝里，然后往下垫一小块混凝土碎石，然后轻轻松松的扳两下，就撬开了，亏我高中的时候引以为傲的物理成绩，作为物理课代表，这么浅显易懂的杠杆原理都完全不会用到生活里，后面在用这个技巧撬的过程中，真的觉得自己蠢到家了，当然在明白了用点杠杆原理之后，撬地板的活就变得慢慢悠悠，悠哉悠哉的了(其实还是很热的，披着毛巾擦眼睛)。
上午的活差不多完了，后面就是把撬出来的混凝土和地板条丢下去，地上铺着不用了的被子，然后就是午饭和午休环节了，午饭换了一家快餐，味道非常可以，下午的活就比较单调了，帮忙清理了上去扔下来的混凝土碎块跟木条，然后稍微打扫了下，老丈人就让我们回家了，接着上次说的，还是觉得比跑步啥的消耗大太多了，那汗流的，一口就能喝完一瓶 500 毫升左右的矿泉水。
+ 聊聊最近平淡的生活之《花束般的恋爱》观后感
+ /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 分吧，勉强及格，好的影视剧应该源于生活高于生活，这一部可能还比不上生活。
]]>
生活
- 运动
- 跑步
- 干活
生活
- 运动
- 减肥
- 跑步
- 干活
+ 看剧
@@ -14045,4 +13902,147 @@ function hiicu64() {
高速
+
+ 聊聊 Sharding-Jdbc 的简单使用
+ /2021/12/12/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E7%9A%84%E7%AE%80%E5%8D%95%E4%BD%BF%E7%94%A8/
+ 我们在日常工作中还是使用比较多的分库分表组件的，其中比较优秀的就有 Sharding-Jdbc，一开始由当当开源，后来捐献给了 Apache，说一下简单使用，因为原来经常的使用都是基于 xml 跟 properties 组合起来使用，这里主要试下用 Java Config 来配置
首先是通过 Spring Initializr 创建个带 jdbc 的 Spring Boot 项目，然后引入主要的依赖
+<dependency>
+ <groupId>org.apache.shardingsphere</groupId>
+ <artifactId>shardingsphere-jdbc-core</artifactId>
+ <version>5.0.0-beta</version>
+</dependency>
+因为前面有聊过 Spring Boot 的自动加载，在这里 spring 就会自己去找 DataSource 的配置，所以要在入口把它干掉
+@SpringBootApplication(exclude = { DataSourceAutoConfiguration.class})
+public class ShardingJdbcDemoApplication implements CommandLineRunner {
+然后因为想在入口跑代码，就实现了下 org.springframework.boot.CommandLineRunner 主要是后面的 Java Config 代码
+
+// 注意这里的注解，可以让 Spring 自动帮忙加载，也就是 Java Config 的核心
+@Configuration
+public class MysqlConfig {
+
+ @Bean
+ public DataSource dataSource() throws SQLException {
+ // Configure actual data sources
+ Map<String, DataSource> dataSourceMap = new HashMap<>();
+
+
+ // Configure the first data source
+ // 使用了默认的Hikari连接池的 DataSource
+ HikariDataSource dataSource1 = new HikariDataSource();
+ dataSource1.setDriverClassName("com.mysql.jdbc.Driver");
+ dataSource1.setJdbcUrl("jdbc:mysql://localhost:3306/sharding");
+ dataSource1.setUsername("username");
+ dataSource1.setPassword("password");
+ dataSourceMap.put("ds0", dataSource1);
+
+ // Configure student table rule
+ // 这里是配置分表逻辑，逻辑表是 student，对应真实的表是 student_0 到 student_1, 这个配置方式就是有多少表可以用 student_$->{0..n}
+ ShardingTableRuleConfiguration studentTableRuleConfig = new ShardingTableRuleConfiguration("student", "ds0.student_$->{0..1}");
+
+ // 设置分表字段
+ studentTableRuleConfig.setTableShardingStrategy(new StandardShardingStrategyConfiguration("user_id", "tableShardingAlgorithm"));
+
+
+ // Configure sharding rule
+ // 配置 studentTableRuleConfig
+ ShardingRuleConfiguration shardingRuleConfig = new ShardingRuleConfiguration();
+ shardingRuleConfig.getTables().add(studentTableRuleConfig);
+
+ // Configure table sharding algorithm
+ Properties tableShardingAlgorithmrProps = new Properties();
+ // 算法表达式就是根据 user_id 对 2 进行取模
+ tableShardingAlgorithmrProps.setProperty("algorithm-expression", "student_${user_id % 2}");
+ shardingRuleConfig.getShardingAlgorithms().put("tableShardingAlgorithm", new ShardingSphereAlgorithmConfiguration("INLINE", tableShardingAlgorithmrProps));
+
+
+ // 然后创建这个 DataSource
+ return ShardingSphereDataSourceFactory.createDataSource(dataSourceMap, Collections.singleton(shardingRuleConfig), new Properties());
+
+ }
+}
+然后我们就可以在使用这个 DataSource 了，先看下这两个表的数据
![]()
![]()
+@Override
+ public void run(String... args) {
+ LOGGER.info("run here");
+ String sql = "SELECT * FROM student WHERE user_id=? ";
+ try (
+ Connection conn = dataSource.getConnection();
+ PreparedStatement ps = conn.prepareStatement(sql)) {
+ // 参数就是 user_id，然后也是分表键，对 2 取模就是 1，应该是去 student_1 取数据
+ ps.setInt(1, 1001);
+
+ ResultSet resultSet = ps.executeQuery();
+ while (resultSet.next()) {
+ final int id = resultSet.getInt("id");
+ final String name = resultSet.getString("name");
+ final int userId = resultSet.getInt("user_id");
+ final int age = resultSet.getInt("age");
+ System.out.println("奇数表 id：" + id + " 姓名：" + name
+ + " 用户 id：" + userId + " 年龄：" + age );
+ System.out.println("=============================");
+ }
+ // 参数就是 user_id，然后也是分表键，对 2 取模就是 0，应该是去 student_0 取数据
+ ps.setInt(1, 1000);
+ resultSet = ps.executeQuery();
+ while (resultSet.next()) {
+ final int id = resultSet.getInt("id");
+ final String name = resultSet.getString("name");
+ final int userId = resultSet.getInt("user_id");
+ final int age = resultSet.getInt("age");
+ System.out.println("偶数表 id：" + id + " 姓名：" + name
+ + " 用户 id：" + userId + " 年龄：" + age );
+ System.out.println("=============================");
+ }
+ } catch (SQLException e) {
+ e.printStackTrace();
+ }
+ }
+看下查询结果
![]()
+]]>
+
+ Java
+
+
+ Java
+ Sharding-Jdbc
+
+
+
+ 关于读书打卡与分享
+ /2021/02/07/%E5%85%B3%E4%BA%8E%E8%AF%BB%E4%B9%A6%E6%89%93%E5%8D%A1%E4%B8%8E%E5%88%86%E4%BA%AB/
+ 最近群里大佬发起了一个读书打卡活动，需要每天读一会书，在群里打卡分享感悟，争取一个月能读完一本书，说实话一天十分钟的读书时间倒是问题不大，不过每天都要打卡，而且一个月要读完一本书，其实难度还是有点大的，不过也想试试看。
之前某某老大给自己立了个 flag，说要读一百本书，这对我来说挺难实现的，一则我也不喜欢书只读一小半，二则感觉对于喜欢看的内容范围还是比较有限制，可能也算是比较矫情，不爱追热门的各类东西，因为往往会有一些跟大众不一致的观点看法，显得格格不入。所以还是这个打卡活动可能会比较适合我，书是人类进步的阶梯。
到现在是打卡了三天了，读的主要是白岩松的《幸福了吗》，对于白岩松，我们这一代人是比较熟悉，并且整体印象比较不错的一个央视主持人，从《焦点访谈》开始，到疫情期间的各类一线节目，可能对我来说是个三观比较正，敢于说一些真话的主持人，这中间其实是有个空档期，没怎么看电视，也不太关注了，只是在疫情期间的节目，还是一如既往地给人一种可靠的感觉，正好有一次偶然微信读书推荐了白岩松的这本书，就看了一部分，正好这次继续往下看，因为相对来讲不会很晦涩，并且从这位知名央视主持人的角度分享他的过往和想法看法，还是比较有意思的。
从对汶川地震，08 年奥运等往事的回忆和一些细节的呈现，也让我了解比较多当时所不知道的，特别是汶川地震，那时的我还在读高中，真的是看着电视，作为“猛男”都忍不住泪目了，共和国之殇，多难兴邦，但是这对于当事人来说，都是一场醒不过来的噩梦。
然后是对于足球的热爱，其实光这个就能掰扯很多，因为我不爱足球，只爱篮球，其中原因有的没的也挺多可以说的，但是看了他的书，才能比较深入的了解一个足球迷，对足球，对中国足球，对世界杯，对阿根廷的感情。
接下去还是想能继续坚持下去，加油！
+]]>
+
+ 生活
+ 读后感
+ 白岩松
+ 幸福了吗
+
+
+ 读后感
+ 读书
+ 打卡
+ 幸福了吗
+ 足球
+
+
+
+ 这周末我又在老丈人家打了天小工
+ /2020/08/30/%E8%BF%99%E5%91%A8%E6%9C%AB%E6%88%91%E5%8F%88%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 俩人晚起了一点，我真的是只要有事，早上就醒的很早，准备八点出发的，六点就醒了，然后想继续睡就一直做梦🤦♂️，差不多八点半多到的丈人家，他们应该已经干了有一会了，我们到了以后就分配给我撬地板的活，上次说的那个敲掉柜子的房间里，还铺着质地还不错的木地板，但是也不想要了，得撬掉重新铺。
拿着撬棍和榔头就上楼去干了，浙江这几天的天气，最高温度一般 38、9，楼上那个房间也没风扇，有了也不能用，都是灰尘，撬了两下，我感觉我体内的水就像真气爆发一样变成汗炸了出来，眼睛全被汗糊住了，可能大部分人不太了解地板是怎么铺的，一般是在地面先铺一层混凝土，混凝土中间嵌进去规则的长条木条，然后真正的地板一块块的都是钉在那个木条上，用那种气枪钉和普通的钉子，并且块跟块之前还有一个木头的槽结构相互耦合，然后边缘的一圈在用较薄的木板将整个木地板封边(这些词都是我现造的)，边缘的用的钉子会更多，所以那几下真的很用力，而且撬地板，得蹲下起来，如此反复，对于我这个体重快超过身高的中年人来说的确是非常大的挑战，接下来继续撬了几个，已经有种要虚脱晕倒的感觉了，及时去喝水擦了汗，又歇了一会，为啥一上来就这么拼呢，主要是因为那个房间丈人在干活的时候是直接看得到的🤦♂️，后来被 LD 一顿教育，本来就是去帮忙的，又不是专业做这个的，急啥。
喝了水之后，又稍稍歇了一会，就开始继续撬了，本来觉得这个地板撬着好像还行，房间不大，没多久就撬完了，撬完之后喝了点饮料(补充点糖分，早餐吃得少，有点低血糖)，然后看到 LD 在撬下面的木条了，这个动作开始了那天最大的经验值收集行动，前面说了这个木条一般是跟混凝土一块铺上去的，但是谁也没想到，这个混凝土铺上去的时候竟然处理的这么随意，根本没考虑跟下面的贴合，所以撬木条的时候直接把木条跟木条中间大块大块的混凝土一块撬起来了，想想那重量，于是我这靠蛮力干活的，就用力把木条带着混凝土一块撬了起来，还沾沾自喜，但是发现结果是撬起来一块之后，体力值瞬间归零，上一篇我也提到了，其实干这类活也是很有技巧性的，但是上次的是我没学会，可能需要花时间学的，但是这次是LD 用她的纤细胳膊教会我的，我在撬的时候，屏住一口气，双手用力，起，大概是吃好几口奶的力气都用出来了，但是 LD 在我休息的时候，慢慢悠悠的，先把撬棍挤到木条或者混凝土跟下层的缝里，然后往下垫一小块混凝土碎石，然后轻轻松松的扳两下，就撬开了，亏我高中的时候引以为傲的物理成绩，作为物理课代表，这么浅显易懂的杠杆原理都完全不会用到生活里，后面在用这个技巧撬的过程中，真的觉得自己蠢到家了，当然在明白了用点杠杆原理之后，撬地板的活就变得慢慢悠悠，悠哉悠哉的了(其实还是很热的，披着毛巾擦眼睛)。
上午的活差不多完了，后面就是把撬出来的混凝土和地板条丢下去，地上铺着不用了的被子，然后就是午饭和午休环节了，午饭换了一家快餐，味道非常可以，下午的活就比较单调了，帮忙清理了上去扔下来的混凝土碎块跟木条，然后稍微打扫了下，老丈人就让我们回家了，接着上次说的，还是觉得比跑步啥的消耗大太多了，那汗流的，一口就能喝完一瓶 500 毫升左右的矿泉水。
+]]>
+
+ 生活
+ 运动
+ 跑步
+ 干活
+
+
+ 生活
+ 运动
+ 减肥
+ 跑步
+ 干活
+
+
diff --git a/sitemap.xml b/sitemap.xml
index e9e6fbe797..3ca7700d98 100644
--- a/sitemap.xml
+++ b/sitemap.xml
@@ -1426,7 +1426,7 @@
https://nicksxs.me/
- 2022-03-20
+ 2022-03-21
daily
1.0
@@ -1434,1897 +1434,1897 @@
https://nicksxs.me/tags/%E7%94%9F%E6%B4%BB/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/2020/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/2021/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%8B%96%E6%9B%B4/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Java/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/JVM/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/C/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/leetcode/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/java/
- 2022-03-20
- weekly
- 0.2
-
-
-
- https://nicksxs.me/tags/Binary-Tree/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/DFS/
- 2022-03-20
+ https://nicksxs.me/tags/Linked-List/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%BA%8C%E5%8F%89%E6%A0%91/
- 2022-03-20
+ https://nicksxs.me/tags/%E9%A2%98%E8%A7%A3/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E9%A2%98%E8%A7%A3/
- 2022-03-20
+ https://nicksxs.me/tags/Binary-Tree/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Linked-List/
- 2022-03-20
+ https://nicksxs.me/tags/DFS/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%BA%8C%E5%8F%89%E6%A0%91/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/2019/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/c/
- 2022-03-20
+ https://nicksxs.me/tags/%E6%8A%80%E6%9C%AF/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E6%8A%80%E6%9C%AF/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%AF%BB%E4%B9%A6/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%AF%BB%E4%B9%A6/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%B9%B6%E5%8F%91/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/j-u-c/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/aqs/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/condition/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/await/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/signal/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/lock/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/unlock/
- 2022-03-20
+ 2022-03-21
+ weekly
+ 0.2
+
+
+
+ https://nicksxs.me/tags/c/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Apollo/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/value/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%B3%A8%E8%A7%A3/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/environment/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Stream/
- 2022-03-20
+ https://nicksxs.me/tags/Disruptor/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Comparator/
- 2022-03-20
+ https://nicksxs.me/tags/Filter/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E6%8E%92%E5%BA%8F/
- 2022-03-20
+ https://nicksxs.me/tags/Interceptor/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/sort/
- 2022-03-20
+ https://nicksxs.me/tags/AOP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/nullsfirst/
- 2022-03-20
+ https://nicksxs.me/tags/Spring/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Filter/
- 2022-03-20
+ https://nicksxs.me/tags/Tomcat/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Interceptor/
- 2022-03-20
+ https://nicksxs.me/tags/Servlet/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/AOP/
- 2022-03-20
+ https://nicksxs.me/tags/Web/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Spring/
- 2022-03-20
+ https://nicksxs.me/tags/G1/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Tomcat/
- 2022-03-20
+ https://nicksxs.me/tags/GC/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Servlet/
- 2022-03-20
+ https://nicksxs.me/tags/Garbage-First-Collector/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Web/
- 2022-03-20
+ https://nicksxs.me/tags/Stream/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/G1/
- 2022-03-20
+ https://nicksxs.me/tags/Comparator/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/GC/
- 2022-03-20
+ https://nicksxs.me/tags/%E6%8E%92%E5%BA%8F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Garbage-First-Collector/
- 2022-03-20
+ https://nicksxs.me/tags/sort/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E9%80%92%E5%BD%92/
- 2022-03-20
+ https://nicksxs.me/tags/nullsfirst/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Preorder-Traversal/
- 2022-03-20
+ https://nicksxs.me/tags/%E9%80%92%E5%BD%92/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Inorder-Traversal/
- 2022-03-20
+ https://nicksxs.me/tags/Preorder-Traversal/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%89%8D%E5%BA%8F/
- 2022-03-20
+ https://nicksxs.me/tags/Inorder-Traversal/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B8%AD%E5%BA%8F/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%89%8D%E5%BA%8F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Disruptor/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B8%AD%E5%BA%8F/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/DP/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/stack/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/min-stack/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%9C%80%E5%B0%8F%E6%A0%88/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/leetcode-155/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/linked-list/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Lowest-Common-Ancestor-of-a-Binary-Tree/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/string/
- 2022-03-20
+ https://nicksxs.me/tags/Intersection-of-Two-Arrays/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Intersection-of-Two-Arrays/
- 2022-03-20
+ https://nicksxs.me/tags/string/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/dp/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E4%BB%A3%E7%A0%81%E9%A2%98%E8%A7%A3/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Trapping-Rain-Water/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%8E%A5%E9%9B%A8%E6%B0%B4/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Leetcode-42/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Rotate-Image/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%9F%A9%E9%98%B5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Remove-Duplicates-from-Sorted-List/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/linux/
- 2022-03-20
+ https://nicksxs.me/tags/mfc/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/grep/
- 2022-03-20
+ https://nicksxs.me/tags/linux/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%BD%AC%E4%B9%89/
- 2022-03-20
+ https://nicksxs.me/tags/grep/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/mfc/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%BD%AC%E4%B9%89/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Maven/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/C/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Redis/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Distributed-Lock/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/hadoop/
- 2022-03-20
+ https://nicksxs.me/tags/docker/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/cluster/
- 2022-03-20
+ https://nicksxs.me/tags/mysql/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/docker/
- 2022-03-20
+ https://nicksxs.me/tags/hadoop/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/mysql/
- 2022-03-20
+ https://nicksxs.me/tags/cluster/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Docker/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/namespace/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/cgroup/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Dockerfile/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/echo/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/uname/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8F%91%E8%A1%8C%E7%89%88/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Gogs/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Webhook/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8D%9A%E5%AE%A2%EF%BC%8C%E6%96%87%E7%AB%A0/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Mysql/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Mybatis/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Sql%E6%B3%A8%E5%85%A5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%BC%93%E5%AD%98/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/openresty/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/nginx/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/php/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/mq/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/im/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/redis/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%BA%90%E7%A0%81/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%B7%98%E6%B1%B0%E7%AD%96%E7%95%A5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%BA%94%E7%94%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Evict/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%BF%87%E6%9C%9F%E7%AD%96%E7%95%A5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Rust/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%89%80%E6%9C%89%E6%9D%83/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%86%85%E5%AD%98%E5%88%86%E5%B8%83/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%96%B0%E8%AF%AD%E8%A8%80/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8F%AF%E5%8F%98%E5%BC%95%E7%94%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E4%B8%8D%E5%8F%AF%E5%8F%98%E5%BC%95%E7%94%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%88%87%E7%89%87/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/spark/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/python/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Spring-Event/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/websocket/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/swoole/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/WordPress/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%B0%8F%E6%8A%80%E5%B7%A7/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/gc/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%A0%87%E8%AE%B0%E6%95%B4%E7%90%86/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/jvm/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/MQ/
- 2022-03-20
+ https://nicksxs.me/tags/ssh/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/RocketMQ/
- 2022-03-20
+ https://nicksxs.me/tags/MQ/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%89%8A%E5%B3%B0%E5%A1%AB%E8%B0%B7/
- 2022-03-20
+ https://nicksxs.me/tags/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B8%AD%E9%97%B4%E4%BB%B6/
- 2022-03-20
+ https://nicksxs.me/tags/RocketMQ/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/ssh/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%89%8A%E5%B3%B0%E5%A1%AB%E8%B0%B7/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B8%AD%E9%97%B4%E4%BB%B6/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%90%90%E6%A7%BD/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%96%AB%E6%83%85/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%BE%8E%E5%9B%BD/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4%E8%BD%A6/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8F%A3%E7%BD%A9/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%9D%80%E4%BA%BA%E8%AF%9B%E5%BF%83/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%BC%80%E8%BD%A6/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8A%A0%E5%A1%9E/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%B3%9F%E5%BF%83%E4%BA%8B/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%A7%84%E5%88%99/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%B7%AF%E6%94%BF%E8%A7%84%E5%88%92/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%9D%AD%E5%B7%9E/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%81%A5%E5%BA%B7%E7%A0%81/
- 2022-03-20
- weekly
- 0.2
-
-
-
- https://nicksxs.me/tags/%E6%89%93%E5%8D%A1/
- 2022-03-20
- weekly
- 0.2
-
-
-
- https://nicksxs.me/tags/%E5%B9%B8%E7%A6%8F%E4%BA%86%E5%90%97/
- 2022-03-20
- weekly
- 0.2
-
-
-
- https://nicksxs.me/tags/%E8%B6%B3%E7%90%83/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%BF%90%E5%8A%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%87%8F%E8%82%A5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%B7%91%E6%AD%A5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%B9%B2%E6%B4%BB/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/scp/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%BD%B1%E8%AF%84/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/git/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%AF%84%E7%94%9F%E8%99%AB/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%BD%B1%E8%AF%84/
- 2022-03-20
+ https://nicksxs.me/tags/scp/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%AF%84%E7%94%9F%E8%99%AB/
- 2022-03-20
+ https://nicksxs.me/tags/git/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/DefaultMQPushConsumer/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/NameServer/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/SpringBoot/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%AD%97%E7%AC%A6%E9%9B%86/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/cglib/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%BC%96%E7%A0%81/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%BA%8B%E5%8A%A1/
- 2022-03-20
+ https://nicksxs.me/tags/utf8/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Druid/
- 2022-03-20
+ https://nicksxs.me/tags/utf8mb4/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/tags/utf8mb4-0900-ai-ci/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B8%9C%E4%BA%AC%E5%A5%A5%E8%BF%90%E4%BC%9A/
- 2022-03-20
+ https://nicksxs.me/tags/utf8mb4-unicode-ci/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B8%BE%E9%87%8D/
- 2022-03-20
+ https://nicksxs.me/tags/utf8mb4-general-ci/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%B0%84%E5%87%BB/
- 2022-03-20
+ https://nicksxs.me/tags/SpringBoot/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B9%92%E4%B9%93%E7%90%83/
- 2022-03-20
+ https://nicksxs.me/tags/cglib/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%B7%B3%E6%B0%B4/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%BA%8B%E5%8A%A1/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%AD%97%E7%AC%A6%E9%9B%86/
- 2022-03-20
+ https://nicksxs.me/tags/Druid/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%BC%96%E7%A0%81/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/tags/utf8/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B8%9C%E4%BA%AC%E5%A5%A5%E8%BF%90%E4%BC%9A/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/utf8mb4/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B8%BE%E9%87%8D/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/utf8mb4-0900-ai-ci/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%B0%84%E5%87%BB/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/utf8mb4-unicode-ci/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B9%92%E4%B9%93%E7%90%83/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/utf8mb4-general-ci/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%B7%B3%E6%B0%B4/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Dubbo/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/RPC/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/SPI/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Adaptive/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%87%AA%E9%80%82%E5%BA%94%E6%8B%93%E5%B1%95/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/Synchronized/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%81%8F%E5%90%91%E9%94%81/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%BD%BB%E9%87%8F%E7%BA%A7%E9%94%81/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E9%87%8D%E9%87%8F%E7%BA%A7%E9%94%81/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%87%AA%E6%97%8B/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%B1%BB%E5%8A%A0%E8%BD%BD/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8A%A0%E8%BD%BD/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E9%AA%8C%E8%AF%81/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%87%86%E5%A4%87/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%A7%A3%E6%9E%90/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%88%9D%E5%A7%8B%E5%8C%96/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E9%93%BE%E6%8E%A5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8F%8C%E4%BA%B2%E5%A7%94%E6%B4%BE/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/top/
- 2022-03-20
+ https://nicksxs.me/tags/JPS/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Broker/
- 2022-03-20
+ https://nicksxs.me/tags/JStack/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Sharding-Jdbc/
- 2022-03-20
+ https://nicksxs.me/tags/JMap/
+ 2022-03-21
+ weekly
+ 0.2
+
+
+
+ https://nicksxs.me/tags/top/
+ 2022-03-21
+ weekly
+ 0.2
+
+
+
+ https://nicksxs.me/tags/Broker/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/ThreadPool/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%BA%BF%E7%A8%8B%E6%B1%A0/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/FixedThreadPool/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/LimitedThreadPool/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/EagerThreadPool/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/CachedThreadPool/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/JPS/
- 2022-03-20
+ https://nicksxs.me/tags/mvcc/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/JStack/
- 2022-03-20
+ https://nicksxs.me/tags/read-view/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/JMap/
- 2022-03-20
+ https://nicksxs.me/tags/gap-lock/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/mvcc/
- 2022-03-20
+ https://nicksxs.me/tags/next-key-lock/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/read-view/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%B9%BB%E8%AF%BB/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/gap-lock/
- 2022-03-20
+ https://nicksxs.me/tags/Sharding-Jdbc/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/next-key-lock/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%B4%A2%E5%BC%95/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%B9%BB%E8%AF%BB/
- 2022-03-20
+ https://nicksxs.me/tags/is-null/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%B4%A2%E5%BC%95/
- 2022-03-20
+ https://nicksxs.me/tags/is-not-null/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/is-null/
- 2022-03-20
+ https://nicksxs.me/tags/procedure/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/is-not-null/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/procedure/
- 2022-03-20
+ https://nicksxs.me/tags/Design-Patterns/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E7%A9%BF%E9%80%8F/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%8D%95%E4%BE%8B/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E5%87%BB%E7%A9%BF/
- 2022-03-20
+ https://nicksxs.me/tags/Singleton/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E9%9B%AA%E5%B4%A9/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%87%AA%E5%8A%A8%E8%A3%85%E9%85%8D/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8/
- 2022-03-20
+ https://nicksxs.me/tags/AutoConfiguration/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/bloom-filter/
- 2022-03-20
+ https://nicksxs.me/tags/Mac/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%BA%92%E6%96%A5%E9%94%81/
- 2022-03-20
+ https://nicksxs.me/tags/PHP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/
- 2022-03-20
+ https://nicksxs.me/tags/Homebrew/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Design-Patterns/
- 2022-03-20
+ https://nicksxs.me/tags/icu4c/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%8D%95%E4%BE%8B/
- 2022-03-20
+ https://nicksxs.me/tags/zsh/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Singleton/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E7%A9%BF%E9%80%8F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Mac/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E5%87%BB%E7%A9%BF/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/PHP/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E9%9B%AA%E5%B4%A9/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Homebrew/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/icu4c/
- 2022-03-20
+ https://nicksxs.me/tags/bloom-filter/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/zsh/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%BA%92%E6%96%A5%E9%94%81/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/ThreadLocal/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%BC%B1%E5%BC%95%E7%94%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/WeakReference/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%97%85%E6%B8%B8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%8E%A6%E9%97%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E4%B8%AD%E5%B1%B1%E8%B7%AF/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%B1%80%E5%8F%A3%E8%A1%97/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E9%BC%93%E6%B5%AA%E5%B1%BF/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%9B%BE%E5%8E%9D%E5%9E%B5/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%A4%8D%E7%89%A9%E5%9B%AD/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E9%A9%AC%E6%88%8F%E5%9B%A2/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%B2%99%E8%8C%B6%E9%9D%A2/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%B5%B7%E8%9B%8E%E7%85%8E/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E6%89%B6%E6%A2%AF/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E8%B8%A9%E8%B8%8F/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E5%AE%89%E5%85%A8/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/tags/%E7%94%B5%E7%93%B6%E8%BD%A6/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%87%AA%E5%8A%A8%E8%A3%85%E9%85%8D/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/AutoConfiguration/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/Thread-dump/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
- 2022-03-20
+ https://nicksxs.me/tags/2PC/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
- 2022-03-20
+ https://nicksxs.me/tags/3PC/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/
- 2022-03-20
+ https://nicksxs.me/tags/Thread-dump/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/2PC/
- 2022-03-20
+ https://nicksxs.me/tags/%E9%AA%91%E8%BD%A6/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/3PC/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%9C%8B%E5%89%A7/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E9%AA%91%E8%BD%A6/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%A3%85%E7%94%B5%E8%84%91/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%9C%8B%E5%89%A7/
- 2022-03-20
+ https://nicksxs.me/tags/%E8%80%81%E7%94%B5%E8%84%91/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%A3%85%E7%94%B5%E8%84%91/
- 2022-03-20
+ https://nicksxs.me/tags/360-%E5%85%A8%E5%AE%B6%E6%A1%B6/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E8%80%81%E7%94%B5%E8%84%91/
- 2022-03-20
+ https://nicksxs.me/tags/%E4%BF%AE%E7%94%B5%E8%84%91%E7%9A%84/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/360-%E5%85%A8%E5%AE%B6%E6%A1%B6/
- 2022-03-20
+ https://nicksxs.me/tags/%E6%8D%A2%E8%BD%A6%E7%89%8C/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E4%BF%AE%E7%94%B5%E8%84%91%E7%9A%84/
- 2022-03-20
+ https://nicksxs.me/tags/%E7%9C%8B%E4%B9%A6/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E6%8D%A2%E8%BD%A6%E7%89%8C/
- 2022-03-20
+ https://nicksxs.me/tags/%E9%AB%98%E9%80%9F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E7%9C%8B%E4%B9%A6/
- 2022-03-20
+ https://nicksxs.me/tags/%E6%89%93%E5%8D%A1/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/tags/%E9%AB%98%E9%80%9F/
- 2022-03-20
+ https://nicksxs.me/tags/%E5%B9%B8%E7%A6%8F%E4%BA%86%E5%90%97/
+ 2022-03-21
+ weekly
+ 0.2
+
+
+
+ https://nicksxs.me/tags/%E8%B6%B3%E7%90%83/
+ 2022-03-21
weekly
0.2
@@ -3333,1008 +3333,1008 @@
https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/Java/
- 2022-03-20
+ 2022-03-21
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-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/Java/JVM/
- 2022-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/leetcode/
- 2022-03-20
+ 2022-03-21
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-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/Java/GC/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Binary-Tree/
- 2022-03-20
+ https://nicksxs.me/categories/Linked-List/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Linked-List/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2019/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
- 2022-03-20
+ https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/C/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/
- 2022-03-20
+ https://nicksxs.me/categories/Binary-Tree/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/C/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/
- 2022-03-20
+ https://nicksxs.me/categories/Java/%E5%B9%B6%E5%8F%91/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/leetcode/java/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/%E5%B9%B6%E5%8F%91/
- 2022-03-20
+ https://nicksxs.me/categories/java/
+ 2022-03-21
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-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/Java/Apollo/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/Binary-Tree/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/java/
- 2022-03-20
+ https://nicksxs.me/categories/Filter/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/Java/%E9%9B%86%E5%90%88/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/Linked-List/
- 2022-03-20
+ https://nicksxs.me/categories/Java/leetcode/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Filter/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2021/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/leetcode/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2020/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/leetcode/java/Linked-List/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Java/Apollo/value/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/DP/
- 2022-03-20
+ https://nicksxs.me/categories/Interceptor-AOP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/stack/
- 2022-03-20
+ https://nicksxs.me/categories/leetcode/java/Binary-Tree/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/Apollo/value/
- 2022-03-20
+ https://nicksxs.me/categories/Spring/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/linked-list/
- 2022-03-20
+ https://nicksxs.me/categories/leetcode/java/Binary-Tree/DFS/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/Binary-Tree/DFS/
- 2022-03-20
+ https://nicksxs.me/categories/Spring/Servlet/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%AD%97%E7%AC%A6%E4%B8%B2-online/
- 2022-03-20
+ https://nicksxs.me/categories/Spring/Servlet/Interceptor/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Linux/
- 2022-03-20
+ https://nicksxs.me/categories/Spring/Servlet/Interceptor/AOP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/Maven/
- 2022-03-20
+ https://nicksxs.me/categories/DP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Redis/
- 2022-03-20
+ https://nicksxs.me/categories/stack/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Interceptor-AOP/
- 2022-03-20
+ https://nicksxs.me/categories/Java/leetcode/Lowest-Common-Ancestor-of-a-Binary-Tree/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/data-analysis/
- 2022-03-20
+ https://nicksxs.me/categories/linked-list/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/docker/
- 2022-03-20
+ https://nicksxs.me/categories/leetcode/java/DP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Docker/
- 2022-03-20
+ https://nicksxs.me/categories/leetcode/java/stack/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90/
- 2022-03-20
+ https://nicksxs.me/categories/Java/leetcode/Rotate-Image/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/Mybatis/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%AD%97%E7%AC%A6%E4%B8%B2-online/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/nginx/
- 2022-03-20
+ https://nicksxs.me/categories/Linux/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/php/
- 2022-03-20
+ https://nicksxs.me/categories/leetcode/java/linked-list/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/DP/
- 2022-03-20
+ https://nicksxs.me/categories/Java/Maven/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/redis/
- 2022-03-20
+ https://nicksxs.me/categories/Redis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/stack/
- 2022-03-20
+ https://nicksxs.me/categories/docker/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/leetcode/Lowest-Common-Ancestor-of-a-Binary-Tree/
- 2022-03-20
+ https://nicksxs.me/categories/leetcode/java/string/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/
- 2022-03-20
+ https://nicksxs.me/categories/data-analysis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/linked-list/
- 2022-03-20
+ https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/Spring/
- 2022-03-20
+ https://nicksxs.me/categories/Docker/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/
- 2022-03-20
+ https://nicksxs.me/categories/%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/gc/
- 2022-03-20
+ https://nicksxs.me/categories/Redis/Distributed-Lock/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/MQ/
- 2022-03-20
+ https://nicksxs.me/categories/Java/Mybatis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/ssh/
- 2022-03-20
+ https://nicksxs.me/categories/nginx/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/
- 2022-03-20
+ https://nicksxs.me/categories/php/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/leetcode/java/string/
- 2022-03-20
+ https://nicksxs.me/categories/redis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/leetcode/Rotate-Image/
- 2022-03-20
+ https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/grep/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%85%AC%E4%BA%A4/
- 2022-03-20
+ https://nicksxs.me/categories/Redis/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Docker/%E4%BB%8B%E7%BB%8D/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/
- 2022-03-20
+ https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/echo/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/
- 2022-03-20
+ https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/shell/
- 2022-03-20
+ https://nicksxs.me/categories/Java/Spring/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/git/
- 2022-03-20
+ https://nicksxs.me/categories/C/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Redis/Distributed-Lock/
- 2022-03-20
+ https://nicksxs.me/categories/Mysql/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Spring/
- 2022-03-20
+ https://nicksxs.me/categories/Java/gc/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Docker/%E4%BB%8B%E7%BB%8D/
- 2022-03-20
+ https://nicksxs.me/categories/Mybatis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/SpringBoot/
- 2022-03-20
+ https://nicksxs.me/categories/ssh/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mysql/
- 2022-03-20
+ https://nicksxs.me/categories/MQ/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo-RPC-SPI/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo-RPC/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%85%AC%E4%BA%A4/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/%E7%B1%BB%E5%8A%A0%E8%BD%BD/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mybatis/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo-%E7%BA%BF%E7%A8%8B%E6%B1%A0/
- 2022-03-20
+ https://nicksxs.me/categories/shell/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Thread-dump/
- 2022-03-20
+ https://nicksxs.me/categories/git/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Redis/%E5%BA%94%E7%94%A8/
- 2022-03-20
+ https://nicksxs.me/categories/Redis/%E6%BA%90%E7%A0%81/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/Design-Patterns/
- 2022-03-20
+ https://nicksxs.me/categories/Java/SpringBoot/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mac/
- 2022-03-20
+ https://nicksxs.me/categories/Docker/%E5%8F%91%E8%A1%8C%E7%89%88%E6%9C%AC/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Redis/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo-RPC-SPI/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E6%97%85%E6%B8%B8/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo-RPC/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/SpringBoot/
- 2022-03-20
+ https://nicksxs.me/categories/Java/%E7%B1%BB%E5%8A%A0%E8%BD%BD/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
- 2022-03-20
+ https://nicksxs.me/categories/Thread-dump/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BC%80%E8%BD%A6/
- 2022-03-20
+ https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/top/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/Rust/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Rust/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo-%E7%BA%BF%E7%A8%8B%E6%B1%A0/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/gc/jvm/
- 2022-03-20
+ https://nicksxs.me/categories/Rust/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/RocketMQ/
- 2022-03-20
+ https://nicksxs.me/categories/C/Redis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/ssh/%E6%8A%80%E5%B7%A7/
- 2022-03-20
+ https://nicksxs.me/categories/Java/Design-Patterns/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Mac/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/SpringBoot/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/grep/
- 2022-03-20
+ https://nicksxs.me/categories/Redis/%E5%BA%94%E7%94%A8/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Mysql/Sql%E6%B3%A8%E5%85%A5/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/shell/%E5%B0%8F%E6%8A%80%E5%B7%A7/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E6%97%85%E6%B8%B8/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/git/%E5%B0%8F%E6%8A%80%E5%B7%A7/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/C/
- 2022-03-20
+ https://nicksxs.me/categories/Java/gc/jvm/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/2020/
- 2022-03-20
+ https://nicksxs.me/categories/Mybatis/%E7%BC%93%E5%AD%98/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Spring/Servlet/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BC%80%E8%BD%A6/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/MQ/RocketMQ/
- 2022-03-20
+ https://nicksxs.me/categories/ssh/%E6%8A%80%E5%B7%A7/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/echo/
- 2022-03-20
+ https://nicksxs.me/categories/RocketMQ/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/%E7%96%AB%E6%83%85/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mysql/Sql%E6%B3%A8%E5%85%A5/
- 2022-03-20
+ https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E7%99%BD%E5%B2%A9%E6%9D%BE/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mybatis/%E7%BC%93%E5%AD%98/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/%E8%B7%91%E6%AD%A5/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/top/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/2020/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mysql/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/
- 2022-03-20
+ https://nicksxs.me/categories/shell/%E5%B0%8F%E6%8A%80%E5%B7%A7/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mysql/%E7%B4%A2%E5%BC%95/
- 2022-03-20
+ https://nicksxs.me/categories/git/%E5%B0%8F%E6%8A%80%E5%B7%A7/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Redis/%E7%BC%93%E5%AD%98/
- 2022-03-20
+ https://nicksxs.me/categories/MQ/RocketMQ/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Java/Singleton/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/PHP/
- 2022-03-20
+ https://nicksxs.me/categories/%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Redis/%E6%BA%90%E7%A0%81/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Mysql/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
- 2022-03-20
+ https://nicksxs.me/categories/Mysql/%E7%B4%A2%E5%BC%95/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Java/Singleton/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/PHP/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/
- 2022-03-20
+ https://nicksxs.me/categories/Redis/%E7%BC%93%E5%AD%98/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/Spring/Mybatis/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/C/Redis/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/categories/Spring/Servlet/Interceptor/
- 2022-03-20
+ https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/MQ/RocketMQ/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/categories/Docker/%E5%8F%91%E8%A1%8C%E7%89%88%E6%9C%AC/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo/SPI/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/categories/Spring/Mybatis/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/%E6%9F%A5%E6%97%A5%E5%BF%97/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/
- 2022-03-20
+ https://nicksxs.me/categories/MQ/RocketMQ/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo/SPI/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mysql/%E6%BA%90%E7%A0%81/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/%E5%B7%A5%E5%85%B7/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/C/Mysql/
- 2022-03-20
+ https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/%E6%8E%92%E5%BA%8F/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/
- 2022-03-20
+ https://nicksxs.me/categories/Mysql/%E6%BA%90%E7%A0%81/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Mac/Homebrew/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/C/Mysql/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/RocketMQ/
- 2022-03-20
+ https://nicksxs.me/categories/Mac/Homebrew/
+ 2022-03-21
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-03-20
+ https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/Spring/Servlet/Interceptor/AOP/
- 2022-03-20
+ 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-03-21
weekly
0.2
- https://nicksxs.me/categories/Dubbo/SPI/Adaptive/
- 2022-03-20
+ https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/RocketMQ/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/%E6%8E%92%E5%BA%8F/
- 2022-03-20
+ https://nicksxs.me/categories/Dubbo/SPI/Adaptive/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/ThreadPool/
- 2022-03-20
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/%E7%A9%BF%E9%80%8F/
- 2022-03-20
+ https://nicksxs.me/categories/PHP/icu4c/
+ 2022-03-21
weekly
0.2
- https://nicksxs.me/categories/PHP/icu4c/
- 2022-03-20
+ https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/%E7%A9%BF%E9%80%8F/
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/%E4%B8%AD%E9%97%B4%E4%BB%B6/
- 2022-03-20
+ 2022-03-21
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-03-20
+ 2022-03-21
weekly
0.2
https://nicksxs.me/categories/%E4%B8%AD%E9%97%B4%E4%BB%B6/RocketMQ/
- 2022-03-20
+ 2022-03-21
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-03-20
+ 2022-03-21
weekly
0.2
-
