From 42ddb4e81c5a30bf3a94e66df73b5fcc894c0dc8 Mon Sep 17 00:00:00 2001 From: nicksxs Date: Mon, 22 Aug 2022 11:10:23 +0800 Subject: [PATCH] Site updated: 2022-08-22 11:10:21 --- .../聊聊-Linux-下的-top-命令/index.html | 4 +- 2021/07/18/2021-年中总结/index.html | 2 +- .../index.html | 2 +- atom.xml | 4 +- baidusitemap.xml | 16 +- index.html | 2 +- leancloud.memo | 1 + leancloud_counter_security_urls.json | 2 +- search.xml | 3022 ++++++++--------- sitemap.xml | 1286 +++---- tags/DP/index.html | 2 +- tags/JVM/index.html | 2 +- tags/linked-list/index.html | 2 +- tags/mysql/index.html | 2 +- tags/php/index.html | 2 +- 15 files changed, 2176 insertions(+), 2175 deletions(-) diff --git a/2021/03/28/聊聊-Linux-下的-top-命令/index.html b/2021/03/28/聊聊-Linux-下的-top-命令/index.html index 74b9310a4e..d35f3b13f9 100644 --- a/2021/03/28/聊聊-Linux-下的-top-命令/index.html +++ b/2021/03/28/聊聊-Linux-下的-top-命令/index.html @@ -1,4 +1,4 @@ -聊聊 Linux 下的 top 命令 | Nicksxs's Blog

Nicksxs's Blog

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

0%

聊聊 Linux 下的 top 命令

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

top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式

-H  :Threads-mode operation
+聊聊 Linux 下的 top 命令 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
聊聊 Linux 下的 top 命令
 发表于   更新于   分类于  ，  ，  ，  ，  ，   阅读次数：   阅读次数：   Disqus： 
top 命令在日常的 Linux 使用中，特别是做一些服务器的简单状态查看，排查故障都起了比较大的作用，但是由于这个命令看到的东西比较多，一般只会看部分，或者说像我这样就会比较片面地看一些信息，比如默认是进程维度的，可以在启动命令的时候加-H进入线程模式
-H  :Threads-mode operation
             Instructs top to display individual threads.  Without this command-line option a summation of all threads in each process  is  shown.   Later
             this can be changed with the `H' interactive command.
这样就能用在 Java 中去 jstack 中找到对应的线程
其实还有比较重要的两个操作，
一个是在 top 启动状态下，按c键，这样能把比如说是一个 Java 进程，具体的进程命令显示出来
像这样
执行前是这样

执行后是这样

第二个就是排序了
SORTING of task window
 
@@ -22,4 +22,4 @@
                  Moves the sort column to the left unless the current sort field is the first field being displayed.
 
              >  :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 可以将当前活跃的排序列用不同颜色标出来，然后可以通过<和>直接左右移动排序列
© 2022  Nicksxs
   

\ No newline at end of file
+                 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 可以将当前活跃的排序列用不同颜色标出来，然后可以通过<和>直接左右移动排序列

\ No newline at end of file diff --git a/2021/07/18/2021-年中总结/index.html b/2021/07/18/2021-年中总结/index.html index 4d8509ae36..b1ae9994e8 100644 --- a/2021/07/18/2021-年中总结/index.html +++ b/2021/07/18/2021-年中总结/index.html @@ -1 +1 @@ -2021 年中总结 | Nicksxs's Blog

Nicksxs's Blog

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

0%

2021 年中总结

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

又到半年总结时，第一次写总结类型的文章感觉挺好写的，但是后面总觉得这过去的一段时间所做的事情，能力上的成长低于预期，但是是需要总结下，找找问题，顺便展望下未来。

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

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

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

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

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

\ No newline at end of file +2021 年中总结 | Nicksxs's Blog

Nicksxs's Blog

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

0%

2021 年中总结

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

又到半年总结时，第一次写总结类型的文章感觉挺好写的，但是后面总觉得这过去的一段时间所做的事情，能力上的成长低于预期，但是是需要总结下，找找问题，顺便展望下未来。

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

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

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

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

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

\ No newline at end of file diff --git a/2022/08/21/一个-nginx-的简单记忆点/index.html b/2022/08/21/一个-nginx-的简单记忆点/index.html index 8a5150e73b..b714406e7a 100644 --- a/2022/08/21/一个-nginx-的简单记忆点/index.html +++ b/2022/08/21/一个-nginx-的简单记忆点/index.html @@ -1,4 +1,4 @@ -一个 nginx 的简单记忆点 | Nicksxs's Blog

Nicksxs's Blog

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

0%

一个 nginx 的简单记忆点

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

上周在处理一个 nginx 配置的时候，发现了一个之前不理解的小点，说一个场景，就是我们一般的处理方式就是一个 ip 端口只能配置一个域名的服务，比如 https://nicksxs.me 对应配置到 127.0.0.1:443，如果我想要把 https://nicksxs.com 也解析到这个服务器，并转发到不同的下游，这里就需要借助所谓的 SNI 的功能

Server Name Indication

A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.
来源
机翻一下：在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展（SNI，RFC 6066），它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道哪个 它应该用于连接的证书。 目前大多数现代浏览器都支持 SNI，但某些旧的或特殊的客户端可能不使用 SNI。

首先我们需要确认 sni 已被支持

在实际的配置中就可以这样

stream {
+一个 nginx 的简单记忆点 | Nicksxs's Blog
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
一个 nginx 的简单记忆点
 发表于   更新于   分类于   阅读次数：   阅读次数：   Disqus： 
上周在处理一个 nginx 配置的时候，发现了一个之前不理解的小点，说一个场景，就是我们一般的处理方式就是一个 ip 端口只能配置一个域名的服务，比如 https://nicksxs.me 对应配置到 127.0.0.1:443，如果我想要把 https://nicksxs.com 也解析到这个服务器，并转发到不同的下游，这里就需要借助所谓的 SNI 的功能
Server Name Indication
A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.
来源
机翻一下：在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展（SNI，RFC 6066），它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道哪个 它应该用于连接的证书。 目前大多数现代浏览器都支持 SNI，但某些旧的或特殊的客户端可能不使用 SNI。
首先我们需要确认 sni 已被支持

在实际的配置中就可以这样
stream {
   map $ssl_preread_server_name $stream_map {
     nicksxs.me nme;
     nicksxs.com ncom;
diff --git a/atom.xml b/atom.xml
index 7e097625fa..d36755fae5 100644
--- a/atom.xml
+++ b/atom.xml
@@ -6,7 +6,7 @@
   
   
   
-  2022-08-21T12:46:13.324Z
+  2022-08-22T03:09:18.925Z
   https://nicksxs.me/
   
   
@@ -21,7 +21,7 @@
     
     https://nicksxs.me/2022/08/21/%E4%B8%80%E4%B8%AA-nginx-%E7%9A%84%E7%AE%80%E5%8D%95%E8%AE%B0%E5%BF%86%E7%82%B9/
     2022-08-21T12:46:13.000Z
-    2022-08-21T12:46:13.324Z
+    2022-08-22T03:09:18.925Z
     
     
       
diff --git a/baidusitemap.xml b/baidusitemap.xml
index 0a58537cf1..c993e90992 100644
--- a/baidusitemap.xml
+++ b/baidusitemap.xml
@@ -2,7 +2,7 @@
 
   
     https://nicksxs.me/2022/08/21/%E4%B8%80%E4%B8%AA-nginx-%E7%9A%84%E7%AE%80%E5%8D%95%E8%AE%B0%E5%BF%86%E7%82%B9/
-    2022-08-21
+    2022-08-22
   
   
     https://nicksxs.me/2022/04/17/nginx-%E6%97%A5%E5%BF%97%E5%B0%8F%E8%AE%B0/
@@ -85,15 +85,15 @@
     2022-06-11
   
   
-    https://nicksxs.me/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/
+    https://nicksxs.me/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/
     2022-06-11
   
   
-    https://nicksxs.me/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/
+    https://nicksxs.me/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/
     2022-06-11
   
   
-    https://nicksxs.me/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/
+    https://nicksxs.me/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/
     2022-06-11
   
   
@@ -621,11 +621,11 @@
     2020-01-12
   
   
-    https://nicksxs.me/2019/12/26/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D/
+    https://nicksxs.me/2020/01/10/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%B8%89/
     2020-01-12
   
   
-    https://nicksxs.me/2020/01/10/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%B8%89/
+    https://nicksxs.me/2019/12/26/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D/
     2020-01-12
   
   
@@ -673,11 +673,11 @@
     2020-01-12
   
   
-    https://nicksxs.me/2016/10/12/summary-ranges-228/
+    https://nicksxs.me/2016/07/13/swoole-websocket-test/
     2020-01-12
   
   
-    https://nicksxs.me/2016/07/13/swoole-websocket-test/
+    https://nicksxs.me/2016/10/12/summary-ranges-228/
     2020-01-12
   
   
diff --git a/index.html b/index.html
index e4e8f01386..c008f2f04f 100644
--- a/index.html
+++ b/index.html
@@ -1,4 +1,4 @@
-Nicksxs's Blog - What hurts more, the pain of hard work or the pain of regret?
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
 发表于   分类于   阅读次数：   Disqus： 
上周在处理一个 nginx 配置的时候，发现了一个之前不理解的小点，说一个场景，就是我们一般的处理方式就是一个 ip 端口只能配置一个域名的服务，比如 https://nicksxs.me 对应配置到 127.0.0.1:443，如果我想要把 https://nicksxs.com 也解析到这个服务器，并转发到不同的下游，这里就需要借助所谓的 SNI 的功能
Server Name Indication
A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.
来源
机翻一下：在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展（SNI，RFC 6066），它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道哪个 它应该用于连接的证书。 目前大多数现代浏览器都支持 SNI，但某些旧的或特殊的客户端可能不使用 SNI。
首先我们需要确认 sni 已被支持

在实际的配置中就可以这样
stream {
+Nicksxs's Blog - What hurts more, the pain of hard work or the pain of regret?
  
Nicksxs's Blog
What hurts more, the pain of hard work or the pain of regret?
  
 0%
 发表于   更新于   分类于   阅读次数：   Disqus： 
上周在处理一个 nginx 配置的时候，发现了一个之前不理解的小点，说一个场景，就是我们一般的处理方式就是一个 ip 端口只能配置一个域名的服务，比如 https://nicksxs.me 对应配置到 127.0.0.1:443，如果我想要把 https://nicksxs.com 也解析到这个服务器，并转发到不同的下游，这里就需要借助所谓的 SNI 的功能
Server Name Indication
A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.
来源
机翻一下：在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展（SNI，RFC 6066），它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道哪个 它应该用于连接的证书。 目前大多数现代浏览器都支持 SNI，但某些旧的或特殊的客户端可能不使用 SNI。
首先我们需要确认 sni 已被支持

在实际的配置中就可以这样
stream {
   map $ssl_preread_server_name $stream_map {
     nicksxs.me nme;
     nicksxs.com ncom;
diff --git a/leancloud.memo b/leancloud.memo
index 2646a2da10..2ca4ed10b9 100644
--- a/leancloud.memo
+++ b/leancloud.memo
@@ -174,4 +174,5 @@
 {"title":"聊一下 SpringBoot 设置非 web 应用的方法","url":"/2022/07/31/聊一下-SpringBoot-设置非-web-应用的方法/"},
 {"title":"Leetcode 16 最接近的三数之和 ( 3Sum Closest *Medium* ) 题解分析","url":"/2022/08/06/Leetcode-16-最接近的三数之和-3Sum-Closest-Medium-题解分析/"},
 {"title":"Leetcode 278 第一个错误的版本 ( First Bad Version *Easy* ) 题解分析","url":"/2022/08/14/Leetcode-278-第一个错误的版本-First-Bad-Version-Easy-题解分析/"},
+{"title":"一个 nginx 的简单记忆点","url":"/2022/08/21/一个-nginx-的简单记忆点/"},
 ]
\ No newline at end of file
diff --git a/leancloud_counter_security_urls.json b/leancloud_counter_security_urls.json
index 993ee67766..4a8a3b92a7 100644
--- a/leancloud_counter_security_urls.json
+++ b/leancloud_counter_security_urls.json
@@ -1 +1 @@
-[{"title":"2019年终总结","url":"/2020/02/01/2019年终总结/"},{"title":"村上春树《1Q84》读后感","url":"/2019/12/18/1Q84读后感/"},{"title":"2020 年终总结","url":"/2021/03/31/2020-年终总结/"},{"title":"2020年中总结","url":"/2020/07/11/2020年中总结/"},{"title":"2021 年中总结","url":"/2021/07/18/2021-年中总结/"},{"title":"2021 年终总结","url":"/2022/01/22/2021-年终总结/"},{"title":"34_Search_for_a_Range","url":"/2016/08/14/34-Search-for-a-Range/"},{"title":"AQS篇二 之 Condition 浅析笔记","url":"/2021/02/21/AQS-之-Condition-浅析笔记/"},{"title":"AQS篇一","url":"/2021/02/14/AQS篇一/"},{"title":"AbstractQueuedSynchronizer","url":"/2019/09/23/AbstractQueuedSynchronizer/"},{"title":"add-two-number","url":"/2015/04/14/Add-Two-Number/"},{"title":"Apollo 的 value 注解是怎么自动更新的","url":"/2020/11/01/Apollo-的-value-注解是怎么自动更新的/"},{"title":"Clone Graph Part I","url":"/2014/12/30/Clone-Graph-Part-I/"},{"title":"Comparator使用小记","url":"/2020/04/05/Comparator使用小记/"},{"title":"Disruptor 系列一","url":"/2022/02/13/Disruptor-系列一/"},{"title":"Disruptor 系列二","url":"/2022/02/27/Disruptor-系列二/"},{"title":"Dubbo 使用的几个记忆点","url":"/2022/04/02/Dubbo-使用的几个记忆点/"},{"title":"Filter, Interceptor, Aop, 啥, 啥, 啥? 这些都是啥?","url":"/2020/08/22/Filter-Intercepter-Aop-啥-啥-啥-这些都是啥/"},{"title":"G1收集器概述","url":"/2020/02/09/G1收集器概述/"},{"title":"JVM源码分析之G1垃圾收集器分析一","url":"/2019/12/07/JVM-G1-Part-1/"},{"title":"Leetcode 021 合并两个有序链表 ( Merge Two Sorted Lists ) 题解分析","url":"/2021/10/07/Leetcode-021-合并两个有序链表-Merge-Two-Sorted-Lists-题解分析/"},{"title":"Leetcode 028 实现 strStr() ( Implement strStr() ) 题解分析","url":"/2021/10/31/Leetcode-028-实现-strStr-Implement-strStr-题解分析/"},{"title":"Leetcode 053 最大子序和 ( Maximum Subarray ) 题解分析","url":"/2021/11/28/Leetcode-053-最大子序和-Maximum-Subarray-题解分析/"},{"title":"Leetcode 104 二叉树的最大深度(Maximum Depth of Binary Tree) 题解分析","url":"/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/"},{"title":"Leetcode 105 从前序与中序遍历序列构造二叉树(Construct Binary Tree from Preorder and Inorder Traversal) 题解分析","url":"/2020/12/13/Leetcode-105-从前序与中序遍历序列构造二叉树-Construct-Binary-Tree-from-Preorder-and-Inorder-Traversal-题解分析/"},{"title":"Leetcode 1115 交替打印 FooBar ( Print FooBar Alternately *Medium* ) 题解分析","url":"/2022/05/01/Leetcode-1115-交替打印-FooBar-Print-FooBar-Alternately-Medium-题解分析/"},{"title":"Leetcode 121 买卖股票的最佳时机(Best Time to Buy and Sell Stock) 题解分析","url":"/2021/03/14/Leetcode-121-买卖股票的最佳时机-Best-Time-to-Buy-and-Sell-Stock-题解分析/"},{"title":"Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析","url":"/2021/01/24/Leetcode-124-二叉树中的最大路径和-Binary-Tree-Maximum-Path-Sum-题解分析/"},{"title":"Leetcode 1260 二维网格迁移 ( Shift 2D Grid *Easy* ) 题解分析","url":"/2022/07/22/Leetcode-1260-二维网格迁移-Shift-2D-Grid-Easy-题解分析/"},{"title":"Leetcode 155 最小栈(Min Stack) 题解分析","url":"/2020/12/06/Leetcode-155-最小栈-Min-Stack-题解分析/"},{"title":"Leetcode 16 最接近的三数之和 ( 3Sum Closest *Medium* ) 题解分析","url":"/2022/08/06/Leetcode-16-最接近的三数之和-3Sum-Closest-Medium-题解分析/"},{"title":"Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析","url":"/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/"},{"title":"Leetcode 2 Add Two Numbers 题解分析","url":"/2020/10/11/Leetcode-2-Add-Two-Numbers-题解分析/"},{"title":"Leetcode 234 回文链表(Palindrome Linked List) 题解分析","url":"/2020/11/15/Leetcode-234-回文联表-Palindrome-Linked-List-题解分析/"},{"title":"Leetcode 236 二叉树的最近公共祖先(Lowest Common Ancestor of a Binary Tree) 题解分析","url":"/2021/05/23/Leetcode-236-二叉树的最近公共祖先-Lowest-Common-Ancestor-of-a-Binary-Tree-题解分析/"},{"title":"Leetcode 278 第一个错误的版本 ( First Bad Version *Easy* ) 题解分析","url":"/2022/08/14/Leetcode-278-第一个错误的版本-First-Bad-Version-Easy-题解分析/"},{"title":"Leetcode 3 Longest Substring Without Repeating Characters 题解分析","url":"/2020/09/20/Leetcode-3-Longest-Substring-Without-Repeating-Characters-题解分析/"},{"title":"Leetcode 349 两个数组的交集 ( Intersection of Two Arrays *Easy* ) 题解分析","url":"/2022/03/07/Leetcode-349-两个数组的交集-Intersection-of-Two-Arrays-Easy-题解分析/"},{"title":"Leetcode 4 寻找两个正序数组的中位数 ( Median of Two Sorted Arrays *Hard* ) 题解分析","url":"/2022/03/27/Leetcode-4-寻找两个正序数组的中位数-Median-of-Two-Sorted-Arrays-Hard-题解分析/"},{"title":"Leetcode 42 接雨水 (Trapping Rain Water) 题解分析","url":"/2021/07/04/Leetcode-42-接雨水-Trapping-Rain-Water-题解分析/"},{"title":"Leetcode 48 旋转图像(Rotate Image) 题解分析","url":"/2021/05/01/Leetcode-48-旋转图像-Rotate-Image-题解分析/"},{"title":"Leetcode 698 划分为k个相等的子集 ( Partition to K Equal Sum Subsets *Medium* ) 题解分析","url":"/2022/06/19/Leetcode-698-划分为k个相等的子集-Partition-to-K-Equal-Sum-Subsets-Medium-题解分析/"},{"title":"Leetcode 83 删除排序链表中的重复元素 ( Remove Duplicates from Sorted List *Easy* ) 题解分析","url":"/2022/03/13/Leetcode-83-删除排序链表中的重复元素-Remove-Duplicates-from-Sorted-List-Easy-题解分析/"},{"title":"leetcode no.3","url":"/2015/04/15/Leetcode-No-3/"},{"title":"Linux 下 grep 命令的一点小技巧","url":"/2020/08/06/Linux-下-grep-命令的一点小技巧/"},{"title":"MFC 模态对话框","url":"/2014/12/24/MFC 模态对话框/"},{"title":"Maven实用小技巧","url":"/2020/02/16/Maven实用小技巧/"},{"title":"Number of 1 Bits","url":"/2015/03/11/Number-Of-1-Bits/"},{"title":"Redis_分布式锁","url":"/2019/12/10/Redis-Part-1/"},{"title":"Path Sum","url":"/2015/01/04/Path-Sum/"},{"title":"Reverse Bits","url":"/2015/03/11/Reverse-Bits/"},{"title":"Reverse Integer","url":"/2015/03/13/Reverse-Integer/"},{"title":"two sum","url":"/2015/01/14/Two-Sum/"},{"title":"ambari-summary","url":"/2017/05/09/ambari-summary/"},{"title":"binary-watch","url":"/2016/09/29/binary-watch/"},{"title":"docker-mysql-cluster","url":"/2016/08/14/docker-mysql-cluster/"},{"title":"docker比一般多一点的初学者介绍","url":"/2020/03/08/docker比一般多一点的初学者介绍/"},{"title":"docker比一般多一点的初学者介绍三","url":"/2020/03/21/docker比一般多一点的初学者介绍三/"},{"title":"docker比一般多一点的初学者介绍二","url":"/2020/03/15/docker比一般多一点的初学者介绍二/"},{"title":"dubbo 客户端配置的一个重要知识点","url":"/2022/06/11/dubbo-客户端配置的一个重要知识点/"},{"title":"docker使用中发现的echo命令的一个小技巧及其他","url":"/2020/03/29/echo命令的一个小技巧/"},{"title":"gogs使用webhook部署react单页应用","url":"/2020/02/22/gogs使用webhook部署react单页应用/"},{"title":"invert-binary-tree","url":"/2015/06/22/invert-binary-tree/"},{"title":"minimum-size-subarray-sum-209","url":"/2016/10/11/minimum-size-subarray-sum-209/"},{"title":"C++ 指针使用中的一个小问题","url":"/2014/12/23/my-new-post/"},{"title":"mybatis 的 foreach 使用的注意点","url":"/2022/07/09/mybatis-的-foreach-使用的注意点/"},{"title":"mybatis 的 $ 和 # 是有啥区别","url":"/2020/09/06/mybatis-的-和-是有啥区别/"},{"title":"mybatis 的缓存是怎么回事","url":"/2020/10/03/mybatis-的缓存是怎么回事/"},{"title":"nginx 日志小记","url":"/2022/04/17/nginx-日志小记/"},{"title":"openresty","url":"/2019/06/18/openresty/"},{"title":"pcre-intro-and-a-simple-package","url":"/2015/01/16/pcre-intro-and-a-simple-package/"},{"title":"php-abstract-class-and-interface","url":"/2016/11/10/php-abstract-class-and-interface/"},{"title":"rabbitmq-tips","url":"/2017/04/25/rabbitmq-tips/"},{"title":"redis 的 rdb 和 COW 介绍","url":"/2021/08/15/redis-的-rdb-和-COW-介绍/"},{"title":"redis数据结构介绍-第一部分 SDS，链表，字典","url":"/2019/12/26/redis数据结构介绍/"},{"title":"redis数据结构介绍三-第三部分 整数集合","url":"/2020/01/10/redis数据结构介绍三/"},{"title":"redis数据结构介绍二-第二部分 跳表","url":"/2020/01/04/redis数据结构介绍二/"},{"title":"redis数据结构介绍五-第五部分 对象","url":"/2020/01/20/redis数据结构介绍五/"},{"title":"redis数据结构介绍六 快表","url":"/2020/01/22/redis数据结构介绍六/"},{"title":"redis数据结构介绍四-第四部分 压缩表","url":"/2020/01/19/redis数据结构介绍四/"},{"title":"redis淘汰策略复习","url":"/2021/08/01/redis淘汰策略复习/"},{"title":"redis系列介绍七-过期策略","url":"/2020/04/12/redis系列介绍七/"},{"title":"redis系列介绍八-淘汰策略","url":"/2020/04/18/redis系列介绍八/"},{"title":"redis过期策略复习","url":"/2021/07/25/redis过期策略复习/"},{"title":"rust学习笔记-所有权三之切片","url":"/2021/05/16/rust学习笔记-所有权三之切片/"},{"title":"rust学习笔记-所有权二","url":"/2021/04/18/rust学习笔记-所有权二/"},{"title":"rust学习笔记-所有权一","url":"/2021/04/18/rust学习笔记/"},{"title":"spark-little-tips","url":"/2017/03/28/spark-little-tips/"},{"title":"spring event 介绍","url":"/2022/01/30/spring-event-介绍/"},{"title":"summary-ranges-228","url":"/2016/10/12/summary-ranges-228/"},{"title":"swoole-websocket-test","url":"/2016/07/13/swoole-websocket-test/"},{"title":"wordpress 忘记密码的一种解决方法","url":"/2021/12/05/wordpress-忘记密码的一种解决方法/"},{"title":"《垃圾回收算法手册读书》笔记之整理算法","url":"/2021/03/07/《垃圾回收算法手册读书》笔记之整理算法/"},{"title":"《长安的荔枝》读后感","url":"/2022/07/17/《长安的荔枝》读后感/"},{"title":"一个 nginx 的简单记忆点","url":"/2022/08/21/一个-nginx-的简单记忆点/"},{"title":"上次的其他 外行聊国足","url":"/2022/03/06/上次的其他-外行聊国足/"},{"title":"介绍一下 RocketMQ","url":"/2020/06/21/介绍一下-RocketMQ/"},{"title":"介绍下最近比较实用的端口转发","url":"/2021/11/14/介绍下最近比较实用的端口转发/"},{"title":"从丁仲礼被美国制裁聊点啥","url":"/2020/12/20/从丁仲礼被美国制裁聊点啥/"},{"title":"从清华美院学姐聊聊我们身边的恶人","url":"/2020/11/29/从清华美院学姐聊聊我们身边的恶人/"},{"title":"关于读书打卡与分享","url":"/2021/02/07/关于读书打卡与分享/"},{"title":"关于公共交通再吐个槽","url":"/2021/03/21/关于公共交通再吐个槽/"},{"title":"分享记录一下一个 git 操作方法","url":"/2022/02/06/分享记录一下一个-git-操作方法/"},{"title":"分享记录一下一个 scp 操作方法","url":"/2022/02/06/分享记录一下一个-scp-操作方法/"},{"title":"周末我在老丈人家打了天小工","url":"/2020/08/16/周末我在老丈人家打了天小工/"},{"title":"在老丈人家的小工记三","url":"/2020/09/13/在老丈人家的小工记三/"},{"title":"在老丈人家的小工记五","url":"/2020/10/18/在老丈人家的小工记五/"},{"title":"在老丈人家的小工记四","url":"/2020/09/26/在老丈人家的小工记四/"},{"title":"寄生虫观后感","url":"/2020/03/01/寄生虫观后感/"},{"title":"屯菜惊魂记","url":"/2022/04/24/屯菜惊魂记/"},{"title":"我是如何走上跑步这条不归路的","url":"/2020/07/26/我是如何走上跑步这条不归路的/"},{"title":"搬运两个 StackOverflow 上的 Mysql 编码相关的问题解答","url":"/2022/01/16/搬运两个-StackOverflow-上的-Mysql-编码相关的问题解答/"},{"title":"是何原因竟让两人深夜奔袭十公里","url":"/2022/06/05/是何原因竟让两人深夜奔袭十公里/"},{"title":"看完了扫黑风暴,聊聊感想","url":"/2021/10/24/看完了扫黑风暴-聊聊感想/"},{"title":"给小电驴上牌","url":"/2022/03/20/给小电驴上牌/"},{"title":"聊一下 RocketMQ 的 DefaultMQPushConsumer 源码","url":"/2020/06/26/聊一下-RocketMQ-的-Consumer/"},{"title":"聊一下 RocketMQ 的 NameServer 源码","url":"/2020/07/05/聊一下-RocketMQ-的-NameServer-源码/"},{"title":"聊一下 RocketMQ 的消息存储之 MMAP","url":"/2021/09/04/聊一下-RocketMQ-的消息存储/"},{"title":"聊一下 RocketMQ 的消息存储三","url":"/2021/10/03/聊一下-RocketMQ-的消息存储三/"},{"title":"聊一下 RocketMQ 的消息存储二","url":"/2021/09/12/聊一下-RocketMQ-的消息存储二/"},{"title":"聊一下 RocketMQ 的消息存储四","url":"/2021/10/17/聊一下-RocketMQ-的消息存储四/"},{"title":"聊一下 RocketMQ 的顺序消息","url":"/2021/08/29/聊一下-RocketMQ-的顺序消息/"},{"title":"聊一下 SpringBoot 中使用的 cglib 作为动态代理中的一个注意点","url":"/2021/09/19/聊一下-SpringBoot-中使用的-cglib-作为动态代理中的一个注意点/"},{"title":"聊一下 SpringBoot 中动态切换数据源的方法","url":"/2021/09/26/聊一下-SpringBoot-中动态切换数据源的方法/"},{"title":"聊一下 SpringBoot 设置非 web 应用的方法","url":"/2022/07/31/聊一下-SpringBoot-设置非-web-应用的方法/"},{"title":"聊在东京奥运会闭幕式这天-二","url":"/2021/08/19/聊在东京奥运会闭幕式这天-二/"},{"title":"聊在东京奥运会闭幕式这天","url":"/2021/08/08/聊在东京奥运会闭幕式这天/"},{"title":"聊聊 Dubbo 的 SPI 续之自适应拓展","url":"/2020/06/06/聊聊-Dubbo-的-SPI-续之自适应拓展/"},{"title":"聊聊 Dubbo 的 SPI","url":"/2020/05/31/聊聊-Dubbo-的-SPI/"},{"title":"聊聊 Dubbo 的容错机制","url":"/2020/11/22/聊聊-Dubbo-的容错机制/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字-二","url":"/2021/06/27/聊聊-Java-中绕不开的-Synchronized-关键字-二/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字","url":"/2021/06/20/聊聊-Java-中绕不开的-Synchronized-关键字/"},{"title":"聊聊 Java 的 equals 和 hashCode 方法","url":"/2021/01/03/聊聊-Java-的-equals-和-hashCode-方法/"},{"title":"聊聊 Java 的类加载机制一","url":"/2020/11/08/聊聊-Java-的类加载机制/"},{"title":"聊聊 Java 的类加载机制二","url":"/2021/06/13/聊聊-Java-的类加载机制二/"},{"title":"聊聊 Java 自带的那些*逆天*工具","url":"/2020/08/02/聊聊-Java-自带的那些逆天工具/"},{"title":"聊聊 Linux 下的 top 命令","url":"/2021/03/28/聊聊-Linux-下的-top-命令/"},{"title":"聊聊 RocketMQ 的 Broker 源码","url":"/2020/07/19/聊聊-RocketMQ-的-Broker-源码/"},{"title":"聊聊 Sharding-Jdbc 分库分表下的分页方案","url":"/2022/01/09/聊聊-Sharding-Jdbc-分库分表下的分页方案/"},{"title":"聊聊 Sharding-Jdbc 的简单使用","url":"/2021/12/12/聊聊-Sharding-Jdbc-的简单使用/"},{"title":"聊聊 Sharding-Jdbc 的简单原理初篇","url":"/2021/12/26/聊聊-Sharding-Jdbc-的简单原理初篇/"},{"title":"聊聊 dubbo 的线程池","url":"/2021/04/04/聊聊-dubbo-的线程池/"},{"title":"聊聊 mysql 的 MVCC 续篇","url":"/2020/05/02/聊聊-mysql-的-MVCC-续篇/"},{"title":"聊聊 mysql 的 MVCC 续续篇之锁分析","url":"/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/"},{"title":"聊聊 mysql 的 MVCC","url":"/2020/04/26/聊聊-mysql-的-MVCC/"},{"title":"聊聊 mysql 索引的一些细节","url":"/2020/12/27/聊聊-mysql-索引的一些细节/"},{"title":"聊聊 redis 缓存的应用问题","url":"/2021/01/31/聊聊-redis-缓存的应用问题/"},{"title":"聊聊Java中的单例模式","url":"/2019/12/21/聊聊Java中的单例模式/"},{"title":"聊聊 SpringBoot 自动装配","url":"/2021/07/11/聊聊SpringBoot-自动装配/"},{"title":"聊聊一次 brew update 引发的血案","url":"/2020/06/13/聊聊一次-brew-update-引发的血案/"},{"title":"聊聊传说中的 ThreadLocal","url":"/2021/05/30/聊聊传说中的-ThreadLocal/"},{"title":"聊聊厦门旅游的好与不好","url":"/2021/04/11/聊聊厦门旅游的好与不好/"},{"title":"聊聊如何识别和意识到日常生活中的各类危险","url":"/2021/06/06/聊聊如何识别和意识到日常生活中的各类危险/"},{"title":"聊聊我刚学会的应用诊断方法","url":"/2020/05/22/聊聊我刚学会的应用诊断方法/"},{"title":"聊聊我理解的分布式事务","url":"/2020/05/17/聊聊我理解的分布式事务/"},{"title":"聊聊我的远程工作体验","url":"/2022/06/26/聊聊我的远程工作体验/"},{"title":"聊聊最近平淡的生活之又聊通勤","url":"/2021/11/07/聊聊最近平淡的生活/"},{"title":"聊聊最近平淡的生活之《花束般的恋爱》观后感","url":"/2021/12/31/聊聊最近平淡的生活之《花束般的恋爱》观后感/"},{"title":"聊聊最近平淡的生活之看《神探狄仁杰》","url":"/2021/12/19/聊聊最近平淡的生活之看《神探狄仁杰》/"},{"title":"聊聊最近平淡的生活之看看老剧","url":"/2021/11/21/聊聊最近平淡的生活之看看老剧/"},{"title":"聊聊给亲戚朋友的老电脑重装系统那些事儿","url":"/2021/05/09/聊聊给亲戚朋友的老电脑重装系统那些事儿/"},{"title":"聊聊这次换车牌及其他","url":"/2022/02/20/聊聊这次换车牌及其他/"},{"title":"聊聊那些加塞狗","url":"/2021/01/17/聊聊那些加塞狗/"},{"title":"聊聊部分公交车的设计bug","url":"/2021/12/05/聊聊部分公交车的设计bug/"},{"title":"记录下 Java Stream 的一些高效操作","url":"/2022/05/15/记录下-Java-Lambda-的一些高效操作/"},{"title":"记录下 zookeeper 集群迁移和易错点","url":"/2022/05/29/记录下-zookeeper-集群迁移/"},{"title":"这周末我又在老丈人家打了天小工","url":"/2020/08/30/这周末我又在老丈人家打了天小工/"},{"title":"重看了下《蛮荒记》说说感受","url":"/2021/10/10/重看了下《蛮荒记》说说感受/"},{"title":"闲聊下乘公交的用户体验","url":"/2021/02/28/闲聊下乘公交的用户体验/"},{"title":"闲话篇-也算碰到了为老不尊和坏人变老了的典型案例","url":"/2022/05/22/闲话篇-也算碰到了为老不尊和坏人变老了的典型案例/"},{"title":"闲话篇-路遇神逻辑骑车带娃爹","url":"/2022/05/08/闲话篇-路遇神逻辑骑车带娃爹/"},{"title":"难得的大扫除","url":"/2022/04/10/难得的大扫除/"},{"title":"Leetcode 20 有效的括号 ( Valid Parentheses *Easy* ) 题解分析","url":"/2022/07/02/Leetcode-20-有效的括号-Valid-Parentheses-Easy-题解分析/"}]
\ No newline at end of file
+[{"title":"2019年终总结","url":"/2020/02/01/2019年终总结/"},{"title":"2020 年终总结","url":"/2021/03/31/2020-年终总结/"},{"title":"2021 年终总结","url":"/2022/01/22/2021-年终总结/"},{"title":"34_Search_for_a_Range","url":"/2016/08/14/34-Search-for-a-Range/"},{"title":"AQS篇二 之 Condition 浅析笔记","url":"/2021/02/21/AQS-之-Condition-浅析笔记/"},{"title":"村上春树《1Q84》读后感","url":"/2019/12/18/1Q84读后感/"},{"title":"2021 年中总结","url":"/2021/07/18/2021-年中总结/"},{"title":"AbstractQueuedSynchronizer","url":"/2019/09/23/AbstractQueuedSynchronizer/"},{"title":"add-two-number","url":"/2015/04/14/Add-Two-Number/"},{"title":"Apollo 的 value 注解是怎么自动更新的","url":"/2020/11/01/Apollo-的-value-注解是怎么自动更新的/"},{"title":"Clone Graph Part I","url":"/2014/12/30/Clone-Graph-Part-I/"},{"title":"AQS篇一","url":"/2021/02/14/AQS篇一/"},{"title":"Disruptor 系列二","url":"/2022/02/27/Disruptor-系列二/"},{"title":"2020年中总结","url":"/2020/07/11/2020年中总结/"},{"title":"Filter, Interceptor, Aop, 啥, 啥, 啥? 这些都是啥?","url":"/2020/08/22/Filter-Intercepter-Aop-啥-啥-啥-这些都是啥/"},{"title":"G1收集器概述","url":"/2020/02/09/G1收集器概述/"},{"title":"JVM源码分析之G1垃圾收集器分析一","url":"/2019/12/07/JVM-G1-Part-1/"},{"title":"Leetcode 021 合并两个有序链表 ( Merge Two Sorted Lists ) 题解分析","url":"/2021/10/07/Leetcode-021-合并两个有序链表-Merge-Two-Sorted-Lists-题解分析/"},{"title":"Leetcode 028 实现 strStr() ( Implement strStr() ) 题解分析","url":"/2021/10/31/Leetcode-028-实现-strStr-Implement-strStr-题解分析/"},{"title":"Leetcode 053 最大子序和 ( Maximum Subarray ) 题解分析","url":"/2021/11/28/Leetcode-053-最大子序和-Maximum-Subarray-题解分析/"},{"title":"Leetcode 104 二叉树的最大深度(Maximum Depth of Binary Tree) 题解分析","url":"/2020/10/25/Leetcode-104-二叉树的最大深度-Maximum-Depth-of-Binary-Tree-题解分析/"},{"title":"Leetcode 105 从前序与中序遍历序列构造二叉树(Construct Binary Tree from Preorder and Inorder Traversal) 题解分析","url":"/2020/12/13/Leetcode-105-从前序与中序遍历序列构造二叉树-Construct-Binary-Tree-from-Preorder-and-Inorder-Traversal-题解分析/"},{"title":"Leetcode 1115 交替打印 FooBar ( Print FooBar Alternately *Medium* ) 题解分析","url":"/2022/05/01/Leetcode-1115-交替打印-FooBar-Print-FooBar-Alternately-Medium-题解分析/"},{"title":"Disruptor 系列一","url":"/2022/02/13/Disruptor-系列一/"},{"title":"Leetcode 124 二叉树中的最大路径和(Binary Tree Maximum Path Sum) 题解分析","url":"/2021/01/24/Leetcode-124-二叉树中的最大路径和-Binary-Tree-Maximum-Path-Sum-题解分析/"},{"title":"Leetcode 1260 二维网格迁移 ( Shift 2D Grid *Easy* ) 题解分析","url":"/2022/07/22/Leetcode-1260-二维网格迁移-Shift-2D-Grid-Easy-题解分析/"},{"title":"Leetcode 121 买卖股票的最佳时机(Best Time to Buy and Sell Stock) 题解分析","url":"/2021/03/14/Leetcode-121-买卖股票的最佳时机-Best-Time-to-Buy-and-Sell-Stock-题解分析/"},{"title":"Leetcode 16 最接近的三数之和 ( 3Sum Closest *Medium* ) 题解分析","url":"/2022/08/06/Leetcode-16-最接近的三数之和-3Sum-Closest-Medium-题解分析/"},{"title":"Leetcode 160 相交链表(intersection-of-two-linked-lists) 题解分析","url":"/2021/01/10/Leetcode-160-相交链表-intersection-of-two-linked-lists-题解分析/"},{"title":"Leetcode 2 Add Two Numbers 题解分析","url":"/2020/10/11/Leetcode-2-Add-Two-Numbers-题解分析/"},{"title":"Leetcode 20 有效的括号 ( Valid Parentheses *Easy* ) 题解分析","url":"/2022/07/02/Leetcode-20-有效的括号-Valid-Parentheses-Easy-题解分析/"},{"title":"Leetcode 234 回文链表(Palindrome Linked List) 题解分析","url":"/2020/11/15/Leetcode-234-回文联表-Palindrome-Linked-List-题解分析/"},{"title":"Leetcode 236 二叉树的最近公共祖先(Lowest Common Ancestor of a Binary Tree) 题解分析","url":"/2021/05/23/Leetcode-236-二叉树的最近公共祖先-Lowest-Common-Ancestor-of-a-Binary-Tree-题解分析/"},{"title":"Leetcode 278 第一个错误的版本 ( First Bad Version *Easy* ) 题解分析","url":"/2022/08/14/Leetcode-278-第一个错误的版本-First-Bad-Version-Easy-题解分析/"},{"title":"Leetcode 3 Longest Substring Without Repeating Characters 题解分析","url":"/2020/09/20/Leetcode-3-Longest-Substring-Without-Repeating-Characters-题解分析/"},{"title":"Leetcode 349 两个数组的交集 ( Intersection of Two Arrays *Easy* ) 题解分析","url":"/2022/03/07/Leetcode-349-两个数组的交集-Intersection-of-Two-Arrays-Easy-题解分析/"},{"title":"Leetcode 4 寻找两个正序数组的中位数 ( Median of Two Sorted Arrays *Hard* ) 题解分析","url":"/2022/03/27/Leetcode-4-寻找两个正序数组的中位数-Median-of-Two-Sorted-Arrays-Hard-题解分析/"},{"title":"Leetcode 42 接雨水 (Trapping Rain Water) 题解分析","url":"/2021/07/04/Leetcode-42-接雨水-Trapping-Rain-Water-题解分析/"},{"title":"Leetcode 48 旋转图像(Rotate Image) 题解分析","url":"/2021/05/01/Leetcode-48-旋转图像-Rotate-Image-题解分析/"},{"title":"Leetcode 698 划分为k个相等的子集 ( Partition to K Equal Sum Subsets *Medium* ) 题解分析","url":"/2022/06/19/Leetcode-698-划分为k个相等的子集-Partition-to-K-Equal-Sum-Subsets-Medium-题解分析/"},{"title":"Leetcode 83 删除排序链表中的重复元素 ( Remove Duplicates from Sorted List *Easy* ) 题解分析","url":"/2022/03/13/Leetcode-83-删除排序链表中的重复元素-Remove-Duplicates-from-Sorted-List-Easy-题解分析/"},{"title":"leetcode no.3","url":"/2015/04/15/Leetcode-No-3/"},{"title":"Linux 下 grep 命令的一点小技巧","url":"/2020/08/06/Linux-下-grep-命令的一点小技巧/"},{"title":"MFC 模态对话框","url":"/2014/12/24/MFC 模态对话框/"},{"title":"Maven实用小技巧","url":"/2020/02/16/Maven实用小技巧/"},{"title":"Number of 1 Bits","url":"/2015/03/11/Number-Of-1-Bits/"},{"title":"Path Sum","url":"/2015/01/04/Path-Sum/"},{"title":"Redis_分布式锁","url":"/2019/12/10/Redis-Part-1/"},{"title":"Reverse Bits","url":"/2015/03/11/Reverse-Bits/"},{"title":"Reverse Integer","url":"/2015/03/13/Reverse-Integer/"},{"title":"two sum","url":"/2015/01/14/Two-Sum/"},{"title":"ambari-summary","url":"/2017/05/09/ambari-summary/"},{"title":"binary-watch","url":"/2016/09/29/binary-watch/"},{"title":"docker-mysql-cluster","url":"/2016/08/14/docker-mysql-cluster/"},{"title":"docker比一般多一点的初学者介绍","url":"/2020/03/08/docker比一般多一点的初学者介绍/"},{"title":"docker比一般多一点的初学者介绍三","url":"/2020/03/21/docker比一般多一点的初学者介绍三/"},{"title":"docker比一般多一点的初学者介绍二","url":"/2020/03/15/docker比一般多一点的初学者介绍二/"},{"title":"dubbo 客户端配置的一个重要知识点","url":"/2022/06/11/dubbo-客户端配置的一个重要知识点/"},{"title":"docker使用中发现的echo命令的一个小技巧及其他","url":"/2020/03/29/echo命令的一个小技巧/"},{"title":"gogs使用webhook部署react单页应用","url":"/2020/02/22/gogs使用webhook部署react单页应用/"},{"title":"invert-binary-tree","url":"/2015/06/22/invert-binary-tree/"},{"title":"minimum-size-subarray-sum-209","url":"/2016/10/11/minimum-size-subarray-sum-209/"},{"title":"C++ 指针使用中的一个小问题","url":"/2014/12/23/my-new-post/"},{"title":"Comparator使用小记","url":"/2020/04/05/Comparator使用小记/"},{"title":"mybatis 的 $ 和 # 是有啥区别","url":"/2020/09/06/mybatis-的-和-是有啥区别/"},{"title":"mybatis 的缓存是怎么回事","url":"/2020/10/03/mybatis-的缓存是怎么回事/"},{"title":"nginx 日志小记","url":"/2022/04/17/nginx-日志小记/"},{"title":"openresty","url":"/2019/06/18/openresty/"},{"title":"mybatis 的 foreach 使用的注意点","url":"/2022/07/09/mybatis-的-foreach-使用的注意点/"},{"title":"pcre-intro-and-a-simple-package","url":"/2015/01/16/pcre-intro-and-a-simple-package/"},{"title":"php-abstract-class-and-interface","url":"/2016/11/10/php-abstract-class-and-interface/"},{"title":"rabbitmq-tips","url":"/2017/04/25/rabbitmq-tips/"},{"title":"redis 的 rdb 和 COW 介绍","url":"/2021/08/15/redis-的-rdb-和-COW-介绍/"},{"title":"redis数据结构介绍三-第三部分 整数集合","url":"/2020/01/10/redis数据结构介绍三/"},{"title":"redis数据结构介绍-第一部分 SDS，链表，字典","url":"/2019/12/26/redis数据结构介绍/"},{"title":"redis数据结构介绍二-第二部分 跳表","url":"/2020/01/04/redis数据结构介绍二/"},{"title":"redis数据结构介绍五-第五部分 对象","url":"/2020/01/20/redis数据结构介绍五/"},{"title":"redis数据结构介绍六 快表","url":"/2020/01/22/redis数据结构介绍六/"},{"title":"redis数据结构介绍四-第四部分 压缩表","url":"/2020/01/19/redis数据结构介绍四/"},{"title":"redis淘汰策略复习","url":"/2021/08/01/redis淘汰策略复习/"},{"title":"redis系列介绍七-过期策略","url":"/2020/04/12/redis系列介绍七/"},{"title":"redis系列介绍八-淘汰策略","url":"/2020/04/18/redis系列介绍八/"},{"title":"redis过期策略复习","url":"/2021/07/25/redis过期策略复习/"},{"title":"rust学习笔记-所有权三之切片","url":"/2021/05/16/rust学习笔记-所有权三之切片/"},{"title":"rust学习笔记-所有权二","url":"/2021/04/18/rust学习笔记-所有权二/"},{"title":"rust学习笔记-所有权一","url":"/2021/04/18/rust学习笔记/"},{"title":"spark-little-tips","url":"/2017/03/28/spark-little-tips/"},{"title":"spring event 介绍","url":"/2022/01/30/spring-event-介绍/"},{"title":"swoole-websocket-test","url":"/2016/07/13/swoole-websocket-test/"},{"title":"wordpress 忘记密码的一种解决方法","url":"/2021/12/05/wordpress-忘记密码的一种解决方法/"},{"title":"summary-ranges-228","url":"/2016/10/12/summary-ranges-228/"},{"title":"《垃圾回收算法手册读书》笔记之整理算法","url":"/2021/03/07/《垃圾回收算法手册读书》笔记之整理算法/"},{"title":"一个 nginx 的简单记忆点","url":"/2022/08/21/一个-nginx-的简单记忆点/"},{"title":"《长安的荔枝》读后感","url":"/2022/07/17/《长安的荔枝》读后感/"},{"title":"介绍一下 RocketMQ","url":"/2020/06/21/介绍一下-RocketMQ/"},{"title":"介绍下最近比较实用的端口转发","url":"/2021/11/14/介绍下最近比较实用的端口转发/"},{"title":"从丁仲礼被美国制裁聊点啥","url":"/2020/12/20/从丁仲礼被美国制裁聊点啥/"},{"title":"从清华美院学姐聊聊我们身边的恶人","url":"/2020/11/29/从清华美院学姐聊聊我们身边的恶人/"},{"title":"关于公共交通再吐个槽","url":"/2021/03/21/关于公共交通再吐个槽/"},{"title":"关于读书打卡与分享","url":"/2021/02/07/关于读书打卡与分享/"},{"title":"分享记录一下一个 git 操作方法","url":"/2022/02/06/分享记录一下一个-git-操作方法/"},{"title":"分享记录一下一个 scp 操作方法","url":"/2022/02/06/分享记录一下一个-scp-操作方法/"},{"title":"周末我在老丈人家打了天小工","url":"/2020/08/16/周末我在老丈人家打了天小工/"},{"title":"在老丈人家的小工记三","url":"/2020/09/13/在老丈人家的小工记三/"},{"title":"上次的其他 外行聊国足","url":"/2022/03/06/上次的其他-外行聊国足/"},{"title":"在老丈人家的小工记五","url":"/2020/10/18/在老丈人家的小工记五/"},{"title":"在老丈人家的小工记四","url":"/2020/09/26/在老丈人家的小工记四/"},{"title":"寄生虫观后感","url":"/2020/03/01/寄生虫观后感/"},{"title":"屯菜惊魂记","url":"/2022/04/24/屯菜惊魂记/"},{"title":"我是如何走上跑步这条不归路的","url":"/2020/07/26/我是如何走上跑步这条不归路的/"},{"title":"Dubbo 使用的几个记忆点","url":"/2022/04/02/Dubbo-使用的几个记忆点/"},{"title":"看完了扫黑风暴,聊聊感想","url":"/2021/10/24/看完了扫黑风暴-聊聊感想/"},{"title":"Leetcode 155 最小栈(Min Stack) 题解分析","url":"/2020/12/06/Leetcode-155-最小栈-Min-Stack-题解分析/"},{"title":"聊一下 RocketMQ 的 DefaultMQPushConsumer 源码","url":"/2020/06/26/聊一下-RocketMQ-的-Consumer/"},{"title":"搬运两个 StackOverflow 上的 Mysql 编码相关的问题解答","url":"/2022/01/16/搬运两个-StackOverflow-上的-Mysql-编码相关的问题解答/"},{"title":"聊一下 RocketMQ 的 NameServer 源码","url":"/2020/07/05/聊一下-RocketMQ-的-NameServer-源码/"},{"title":"是何原因竟让两人深夜奔袭十公里","url":"/2022/06/05/是何原因竟让两人深夜奔袭十公里/"},{"title":"聊一下 RocketMQ 的消息存储三","url":"/2021/10/03/聊一下-RocketMQ-的消息存储三/"},{"title":"聊一下 RocketMQ 的消息存储二","url":"/2021/09/12/聊一下-RocketMQ-的消息存储二/"},{"title":"聊一下 RocketMQ 的消息存储四","url":"/2021/10/17/聊一下-RocketMQ-的消息存储四/"},{"title":"聊一下 RocketMQ 的顺序消息","url":"/2021/08/29/聊一下-RocketMQ-的顺序消息/"},{"title":"聊一下 SpringBoot 中使用的 cglib 作为动态代理中的一个注意点","url":"/2021/09/19/聊一下-SpringBoot-中使用的-cglib-作为动态代理中的一个注意点/"},{"title":"聊一下 SpringBoot 设置非 web 应用的方法","url":"/2022/07/31/聊一下-SpringBoot-设置非-web-应用的方法/"},{"title":"给小电驴上牌","url":"/2022/03/20/给小电驴上牌/"},{"title":"聊在东京奥运会闭幕式这天-二","url":"/2021/08/19/聊在东京奥运会闭幕式这天-二/"},{"title":"聊在东京奥运会闭幕式这天","url":"/2021/08/08/聊在东京奥运会闭幕式这天/"},{"title":"聊聊 Dubbo 的 SPI 续之自适应拓展","url":"/2020/06/06/聊聊-Dubbo-的-SPI-续之自适应拓展/"},{"title":"聊聊 Dubbo 的 SPI","url":"/2020/05/31/聊聊-Dubbo-的-SPI/"},{"title":"聊聊 Dubbo 的容错机制","url":"/2020/11/22/聊聊-Dubbo-的容错机制/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字-二","url":"/2021/06/27/聊聊-Java-中绕不开的-Synchronized-关键字-二/"},{"title":"聊聊 Java 中绕不开的 Synchronized 关键字","url":"/2021/06/20/聊聊-Java-中绕不开的-Synchronized-关键字/"},{"title":"聊聊 Java 的 equals 和 hashCode 方法","url":"/2021/01/03/聊聊-Java-的-equals-和-hashCode-方法/"},{"title":"聊聊 Java 的类加载机制一","url":"/2020/11/08/聊聊-Java-的类加载机制/"},{"title":"聊聊 Java 的类加载机制二","url":"/2021/06/13/聊聊-Java-的类加载机制二/"},{"title":"聊聊 Java 自带的那些*逆天*工具","url":"/2020/08/02/聊聊-Java-自带的那些逆天工具/"},{"title":"聊聊 Linux 下的 top 命令","url":"/2021/03/28/聊聊-Linux-下的-top-命令/"},{"title":"聊聊 RocketMQ 的 Broker 源码","url":"/2020/07/19/聊聊-RocketMQ-的-Broker-源码/"},{"title":"聊聊 Sharding-Jdbc 的简单使用","url":"/2021/12/12/聊聊-Sharding-Jdbc-的简单使用/"},{"title":"聊一下 RocketMQ 的消息存储之 MMAP","url":"/2021/09/04/聊一下-RocketMQ-的消息存储/"},{"title":"聊聊 dubbo 的线程池","url":"/2021/04/04/聊聊-dubbo-的线程池/"},{"title":"聊聊 mysql 的 MVCC 续篇","url":"/2020/05/02/聊聊-mysql-的-MVCC-续篇/"},{"title":"聊聊 mysql 的 MVCC 续续篇之锁分析","url":"/2020/05/10/聊聊-mysql-的-MVCC-续续篇之加锁分析/"},{"title":"聊聊 mysql 的 MVCC","url":"/2020/04/26/聊聊-mysql-的-MVCC/"},{"title":"聊聊 mysql 索引的一些细节","url":"/2020/12/27/聊聊-mysql-索引的一些细节/"},{"title":"聊聊 redis 缓存的应用问题","url":"/2021/01/31/聊聊-redis-缓存的应用问题/"},{"title":"聊聊Java中的单例模式","url":"/2019/12/21/聊聊Java中的单例模式/"},{"title":"聊聊 SpringBoot 自动装配","url":"/2021/07/11/聊聊SpringBoot-自动装配/"},{"title":"聊聊一次 brew update 引发的血案","url":"/2020/06/13/聊聊一次-brew-update-引发的血案/"},{"title":"聊聊传说中的 ThreadLocal","url":"/2021/05/30/聊聊传说中的-ThreadLocal/"},{"title":"聊聊厦门旅游的好与不好","url":"/2021/04/11/聊聊厦门旅游的好与不好/"},{"title":"聊聊如何识别和意识到日常生活中的各类危险","url":"/2021/06/06/聊聊如何识别和意识到日常生活中的各类危险/"},{"title":"聊聊我刚学会的应用诊断方法","url":"/2020/05/22/聊聊我刚学会的应用诊断方法/"},{"title":"聊聊我理解的分布式事务","url":"/2020/05/17/聊聊我理解的分布式事务/"},{"title":"聊聊 Sharding-Jdbc 分库分表下的分页方案","url":"/2022/01/09/聊聊-Sharding-Jdbc-分库分表下的分页方案/"},{"title":"聊聊我的远程工作体验","url":"/2022/06/26/聊聊我的远程工作体验/"},{"title":"聊聊最近平淡的生活之又聊通勤","url":"/2021/11/07/聊聊最近平淡的生活/"},{"title":"聊聊最近平淡的生活之看《神探狄仁杰》","url":"/2021/12/19/聊聊最近平淡的生活之看《神探狄仁杰》/"},{"title":"聊聊最近平淡的生活之看看老剧","url":"/2021/11/21/聊聊最近平淡的生活之看看老剧/"},{"title":"聊聊给亲戚朋友的老电脑重装系统那些事儿","url":"/2021/05/09/聊聊给亲戚朋友的老电脑重装系统那些事儿/"},{"title":"聊一下 SpringBoot 中动态切换数据源的方法","url":"/2021/09/26/聊一下-SpringBoot-中动态切换数据源的方法/"},{"title":"聊聊那些加塞狗","url":"/2021/01/17/聊聊那些加塞狗/"},{"title":"聊聊部分公交车的设计bug","url":"/2021/12/05/聊聊部分公交车的设计bug/"},{"title":"记录下 Java Stream 的一些高效操作","url":"/2022/05/15/记录下-Java-Lambda-的一些高效操作/"},{"title":"记录下 zookeeper 集群迁移和易错点","url":"/2022/05/29/记录下-zookeeper-集群迁移/"},{"title":"这周末我又在老丈人家打了天小工","url":"/2020/08/30/这周末我又在老丈人家打了天小工/"},{"title":"重看了下《蛮荒记》说说感受","url":"/2021/10/10/重看了下《蛮荒记》说说感受/"},{"title":"闲聊下乘公交的用户体验","url":"/2021/02/28/闲聊下乘公交的用户体验/"},{"title":"闲话篇-也算碰到了为老不尊和坏人变老了的典型案例","url":"/2022/05/22/闲话篇-也算碰到了为老不尊和坏人变老了的典型案例/"},{"title":"聊聊这次换车牌及其他","url":"/2022/02/20/聊聊这次换车牌及其他/"},{"title":"闲话篇-路遇神逻辑骑车带娃爹","url":"/2022/05/08/闲话篇-路遇神逻辑骑车带娃爹/"},{"title":"聊聊 Sharding-Jdbc 的简单原理初篇","url":"/2021/12/26/聊聊-Sharding-Jdbc-的简单原理初篇/"},{"title":"聊聊最近平淡的生活之《花束般的恋爱》观后感","url":"/2021/12/31/聊聊最近平淡的生活之《花束般的恋爱》观后感/"},{"title":"难得的大扫除","url":"/2022/04/10/难得的大扫除/"}]
\ No newline at end of file
diff --git a/search.xml b/search.xml
index f3784b722d..7cb23d068c 100644
--- a/search.xml
+++ b/search.xml
@@ -29,26 +29,6 @@
         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,48 +54,6 @@
         拖更
       
   
-  
-    2020年中总结
-    /2020/07/11/2020%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/
-    很快2020 年就过了一半了，而且是今年这么特殊的一年，很多事情都发生的出乎意料，疫情这个绕不过去的话题，之前写了点比较愤青的文字，感觉不太适合发出来就烂在草稿箱里吧，这个目前一大影响估计是今年都没办法完全摘下口罩了，前面几个月来回杭州都开车，因为彭埠大桥不通行了，实在是非常不方便，每条路都灰常堵，心累，吐槽下杭州的交通规划和交警同志，工作实在做的不咋地。

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

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

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

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

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

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

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

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

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

-]]>
-      
-        生活
-        年中总结
-        2021
-      
-      
-        生活
-        2021
-        年中总结
-        技术
-        读书
-      
-  
   
     2021 年终总结
     /2022/01/22/2021-%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/
@@ -677,271 +615,86 @@ public:
       
   
   
-    AQS篇一
-    /2021/02/14/AQS%E7%AF%87%E4%B8%80/
-    很多东西都是时看时新，而且时间长了也会忘，所以再来复习下，也会有一些新的角度看法这次来聊下AQS的内容，主要是这几个点，

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-
解锁
通过代码来看下

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

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

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

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

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

-
static final class Node {
-    // 标识节点当前在共享模式下
-    static final Node SHARED = new Node();
-    // 标识节点当前在独占模式下
-    static final Node EXCLUSIVE = null;
-
-    // ======== 下面的几个int常量是给waitStatus用的 ===========
-    /** waitStatus value to indicate thread has cancelled */
-    // 代码此线程取消了争抢这个锁
-    static final int CANCELLED =  1;
-    /** waitStatus value to indicate successor's thread needs unparking */
-    // 官方的描述是，其表示当前node的后继节点对应的线程需要被唤醒
-    static final int SIGNAL    = -1;
-    /** waitStatus value to indicate thread is waiting on condition */
-    // 本文不分析condition，所以略过吧，下一篇文章会介绍这个
-    static final int CONDITION = -2;
-    /**
-     * waitStatus value to indicate the next acquireShared should
-     * unconditionally propagate
+    // ======== 下面的几个int常量是给waitStatus用的 ===========
+    /** waitStatus value to indicate thread has cancelled */
+    // 代码此线程取消了争抢这个锁
+    static final int CANCELLED =  1;
+    /** waitStatus value to indicate successor's thread needs unparking */
+    // 官方的描述是，其表示当前node的后继节点对应的线程需要被唤醒
+    static final int SIGNAL    = -1;
+    /** waitStatus value to indicate thread is waiting on condition */
+    // 本文不分析condition，所以略过吧，下一篇文章会介绍这个
+    static final int CONDITION = -2;
+    /**
+     * waitStatus value to indicate the next acquireShared should
+     * unconditionally propagate
      */
     // 同样的不分析，略过吧
     static final int PROPAGATE = -3;
@@ -1214,193 +967,231 @@ Node *clone(Node *graph) {
       
   
   
-    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;
+    AQS篇一
+    /2021/02/14/AQS%E7%AF%87%E4%B8%80/
+    很多东西都是时看时新，而且时间长了也会忘，所以再来复习下，也会有一些新的角度看法这次来聊下AQS的内容，主要是这几个点，

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

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

-
-
比较代码

-
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);

+
第二个线程
当第二个线程进来的时候应该是怎么样，结合代码来看

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

 
-
看到这里的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;
+
然后来看下addWaiter的逻辑

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

 
-        @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;
+
然后就是enq的逻辑了

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

-
-
核心代码就是下面这段，其实就是帮我们把前面要做的事情做掉了，是不是挺方便的，小记一下哈

-]]>
-      
-        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;
-
-    public void set(long value) {
-        this.value = value;
-    }
-
-    public long getValue() {
-        return value;
-    }
+        }
+    }

 
-    public void setValue(long value) {
-        this.value = value;
+
所以从这里可以看出来，其实head头结点不是个真实的带有线程的节点，并且不是在第一个线程进来的时候设置的

+
解锁
通过代码来看下

+
/**
+     * Attempts to release this lock.
+     *
+     * <p>If the current thread is the holder of this lock then the hold
+     * count is decremented.  If the hold count is now zero then the lock
+     * is released.  If the current thread is not the holder of this
+     * lock then {@link IllegalMonitorStateException} is thrown.
+     *
+     * @throws IllegalMonitorStateException if the current thread does not
+     *         hold this lock
+     */
+    public void unlock() {
+        // 释放锁
+        sync.release(1);
     }
-}

-
事件生产

-
public class LongEventFactory implements EventFactory<LongEvent>
-{
-    public LongEvent newInstance()
-    {
-        return new LongEvent();
+/**
+     * Releases in exclusive mode.  Implemented by unblocking one or
+     * more threads if {@link #tryRelease} returns true.
+     * This method can be used to implement method {@link Lock#unlock}.
+     *
+     * @param arg the release argument.  This value is conveyed to
+     *        {@link #tryRelease} but is otherwise uninterpreted and
+     *        can represent anything you like.
+     * @return the value returned from {@link #tryRelease}
+     */
+    public final boolean release(int arg) {
+        // 尝试去释放
+        if (tryRelease(arg)) {
+            Node h = head;
+            if (h != null && h.waitStatus != 0)
+                unparkSuccessor(h);
+            return true;
+        }
+        return false;
     }
-}

-
事件处理器

-
public class LongEventHandler implements EventHandler<LongEvent> {
+protected final boolean tryRelease(int releases) {
+            int c = getState() - releases;
+            if (Thread.currentThread() != getExclusiveOwnerThread())
+                throw new IllegalMonitorStateException();
+            boolean free = false;
+    		// 判断是否完全释放锁，因为可重入
+            if (c == 0) {
+                free = true;
+                setExclusiveOwnerThread(null);
+            }
+            setState(c);
+            return free;
+        }
+// 这段代码和上面的一致，只是为了顺序性，又拷下来看下
 
-    // 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);
+public final boolean release(int arg) {
+        // 尝试去释放，如果是完全释放，返回的就是true，否则是false
+        if (tryRelease(arg)) {
+            Node h = head;
+            // 这里判断头结点是否为空以及waitStatus的状态，前面说了head节点其实是
+            // 在第二个线程进来的时候初始化的，如果是空的话说明没后续节点，并且waitStatus
+            // 也表示了后续的等待状态
+            if (h != null && h.waitStatus != 0)
+                unparkSuccessor(h);
+            return true;
+        }
+        return false;
     }
-}
-

-
主方法代码

-
package disruptor;
 
-import com.lmax.disruptor.RingBuffer;
-import com.lmax.disruptor.dsl.Disruptor;
-import com.lmax.disruptor.util.DaemonThreadFactory;
-
-import java.nio.ByteBuffer;
+/**
+     * Wakes up node's successor, if one exists.
+     *
+     * @param node the node
+     */
+// 唤醒后继节点
+    private void unparkSuccessor(Node node) {
+        /*
+         * If status is negative (i.e., possibly needing signal) try
+         * to clear in anticipation of signalling.  It is OK if this
+         * fails or if status is changed by waiting thread.
+         */
+        int ws = node.waitStatus;
+        if (ws < 0)
+            compareAndSetWaitStatus(node, ws, 0);
 
-public class LongEventMain
-{
-    public static void main(String[] args) throws Exception
-    {
-        // 这个需要是 2 的幂次，这样在定位的时候只需要位移操作，也能减少各种计算操作
-        int bufferSize = 1024; 
+        /*
+         * Thread to unpark is held in successor, which is normally
+         * just the next node.  But if cancelled or apparently null,
+         * traverse backwards from tail to find the actual
+         * non-cancelled successor.
+         */
+        Node s = node.next;
+        // 如果后继节点是空或者当前节点取消等待了
+        if (s == null || s.waitStatus > 0) {
+            s = null;
+            // 从后往前找，找到非取消的节点，注意这里不是找到就退出，而是一直找到头
+            // 所以不必担心中间有取消的
+            for (Node t = tail; t != null && t != node; t = t.prev)
+                if (t.waitStatus <= 0)
+                    s = t;
+        }
+        if (s != null)
+            // 将其唤醒
+            LockSupport.unpark(s.thread);
+    }

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

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

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

 ]]>
       
         Java
+        并发
       
       
-        Java
-        Disruptor
+        java
+        并发
+        j.u.c
+        aqs
       
   
   
@@ -1443,25 +1234,22 @@ Node *clone(Node *graph) {
       
   
   
-    Dubbo 使用的几个记忆点
-    /2022/04/02/Dubbo-%E4%BD%BF%E7%94%A8%E7%9A%84%E5%87%A0%E4%B8%AA%E8%AE%B0%E5%BF%86%E7%82%B9/
-    因为后台使用的 dubbo 作为 rpc 框架，并且会有一些日常使用情景有一些小的技巧，在这里做下记录作笔记用

-
dubbo 只拉取不注册
<dubbo:registry address="zookeeper://127.0.0.1:2181" register="false" />

-
就是只要 register="false" 就可以了，这样比如我们在开发环境想运行服务，但又不想让开发环境正常的请求调用到本地来，当然这不是唯一的方式，通过 dubbo 2.7 以上的 tag 路由也可以实现或者自行改造拉取和注册服务的逻辑，因为注册到注册中心的其实是一串带参数的 url，还是比较方便改造的。相反的就是只注册，不拉取

-
dubbo 只注册不拉取
<dubbo:registry address="zookeeper://127.0.0.1:2181" subscribe="false" />

-
这个使用场景就是如果我这个服务只作为 provider，没有任何调用其他的服务，其实就可以这么设置  

-
权重配置
<dubbo:provider loadbalance="random" weight="50"/>

-
首先这是在使用了随机的负载均衡策略的时候可以进行配置，并且是对于多个 provider 的情况下，这样其实也可以部分解决上面的只拉取不注册的问题，我把自己的权重调成 0 或者很低

+    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 这个坎徘徊，等于浪费了大半年，可能是年初的项目太费心力，压力比较大，吃得更多，是不是可以算工伤😄，这方面也需要好好调整，可以放得开一点，虽然不太可能一下子到位，但是总要去努力下，随着年龄成长总要承担更多，也要看得开一点，没法事事如愿，尽力就好了，减肥这个事情还在结合一些俯卧撑啥的，希望也能坚持下去，加油吧，不知道原话怎么说的，意思是人类最大的勇敢就是看透了人世间的苦难，仍然热爱生活。我当然没可能让内心变得这么强大，试着去努力吧，奥力给！

 ]]>
       
-        Java
-        Dubbo
+        生活
+        年中总结
+        2020
       
       
-        Java
-        Dubbo
-        RPC
-        负载均衡
+        生活
+        2020
+        年中总结
       
   
   
@@ -2996,52 +2784,92 @@ inorder = [9,3,15,20,7]
   
-    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/
-    题目介绍
You are given an array prices where prices[i] is the price of a given stock on the ith day.

-
You want to maximize your profit by choosing a single day to buy one stock and choosing a different day in the future to sell that stock.

-
Return the maximum profit you can achieve from this transaction. If you cannot achieve any profit, return 0.

-
给定一个数组 prices ，它的第 i 个元素 prices[i] 表示一支给定股票第 i 天的价格。

-
你只能选择 某一天 买入这只股票，并选择在 未来的某一个不同的日子 卖出该股票。设计一个算法来计算你所能获取的最大利润。

-
返回你可以从这笔交易中获取的最大利润。如果你不能获取任何利润，返回 0 。

-
简单分析
其实这个跟二叉树的最长路径和有点类似，需要找到整体的最大收益，但是在迭代过程中需要一个当前的值

-
int maxSofar = 0;
-public int maxProfit(int[] prices) {
-    if (prices.length <= 1) {
-        return 0;
+    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;
     }
-    int maxIn = prices[0];
-    int maxOut = prices[0];
-    for (int i = 1; i < prices.length; i++) {
-        if (maxIn > prices[i]) {
-            // 当循环当前值小于之前的买入值时就当成买入值，同时卖出也要更新
-            maxIn = prices[i];
-            maxOut = prices[i];
-        }
-        if (prices[i] > maxOut) {
-            // 表示一个可卖出点，即比买入值高时
-            maxOut = prices[i];
-            // 需要设置一个历史值
-            maxSofar = Math.max(maxSofar, maxOut - maxIn);
-        }
+
+    public long getValue() {
+        return value;
     }
-    return maxSofar;
-}

 
-
总结下
一开始看到 easy 就觉得是很简单，就没有 maxSofar ，但是一提交就出现问题了
对于[2, 4, 1]这种就会变成 0，所以还是需要一个历史值来存放历史最大值，这题有点动态规划的意思

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

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

-
示例
Example 1:

-
Input
-["MinStack","push","push","push","getMin","pop","top","getMin"]
-[[],[-2],[0],[-3],[],[],[],[]]
-
-Output
-[null,null,null,null,-3,null,0,-2]
-
-Explanation
-MinStack minStack = new MinStack();
-minStack.push(-2);
-minStack.push(0);
-minStack.push(-3);
-minStack.getMin(); // return -3
-minStack.pop();
-minStack.top();    // return 0
-minStack.getMin(); // return -2

-
-
简要分析
其实现在大部分语言都自带类栈的数据结构，Java 也自带 stack 这个数据结构，所以这个题的主要难点的就是常数级的获取最小元素，最开始的想法是就一个栈外加一个记录最小值的变量就行了，但是仔细一想是不行的，因为随着元素被 pop 出去，这个最小值也可能需要梗着变化，就不太好判断了，所以后面是用了一个辅助栈。

-
代码
class MinStack {
-        // 这个作为主栈
-        Stack<Integer> s1 = new Stack<>();
-        // 这个作为辅助栈，放最小值的栈
-        Stack<Integer> s2 = new Stack<>();
-        /** initialize your data structure here. */
-        public MinStack() {
-
-        }
-
-        public void push(int x) {
-            // 放入主栈
-            s1.push(x);
-            // 当 s2 是空或者当前值是小于"等于" s2 栈顶时，压入辅助最小值的栈
-            // 注意这里的"等于"非常必要，因为当最小值有多个的情况下，也需要压入栈，否则在 pop 的时候就会不对等
-            if (s2.isEmpty() || x <= s2.peek()) {
-                s2.push(x);
-            }
-        }
-
-        public void pop() {
-            // 首先就是主栈要 pop，然后就是第二个了，跟上面的"等于"很有关系，
-            // 因为如果有两个最小值，如果前面等于的情况没有压栈，那这边相等的时候 pop 就会少一个了，可能就导致最小值不对了
-            int x = s1.pop();
-            if (x == s2.peek())  {
-                s2.pop();
-            }
-        }
-
-        public int top() {
-            // 栈顶的元素
-            return s1.peek();
+    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/
+    题目介绍
You are given an array prices where prices[i] is the price of a given stock on the ith day.

+
You want to maximize your profit by choosing a single day to buy one stock and choosing a different day in the future to sell that stock.

+
Return the maximum profit you can achieve from this transaction. If you cannot achieve any profit, return 0.

+
给定一个数组 prices ，它的第 i 个元素 prices[i] 表示一支给定股票第 i 天的价格。

+
你只能选择 某一天 买入这只股票，并选择在 未来的某一个不同的日子 卖出该股票。设计一个算法来计算你所能获取的最大利润。

+
返回你可以从这笔交易中获取的最大利润。如果你不能获取任何利润，返回 0 。

+
简单分析
其实这个跟二叉树的最长路径和有点类似，需要找到整体的最大收益，但是在迭代过程中需要一个当前的值

+
int maxSofar = 0;
+public int maxProfit(int[] prices) {
+    if (prices.length <= 1) {
+        return 0;
+    }
+    int maxIn = prices[0];
+    int maxOut = prices[0];
+    for (int i = 1; i < prices.length; i++) {
+        if (maxIn > prices[i]) {
+            // 当循环当前值小于之前的买入值时就当成买入值，同时卖出也要更新
+            maxIn = prices[i];
+            maxOut = prices[i];
         }
-
-        public int getMin() {
-            // 辅助最小栈的栈顶
-            return s2.peek();
+        if (prices[i] > maxOut) {
+            // 表示一个可卖出点，即比买入值高时
+            maxOut = prices[i];
+            // 需要设置一个历史值
+            maxSofar = Math.max(maxSofar, maxOut - maxIn);
         }
-    }

+    }
+    return maxSofar;
+}

 
+
总结下
一开始看到 easy 就觉得是很简单，就没有 maxSofar ，但是一提交就出现问题了
对于[2, 4, 1]这种就会变成 0，所以还是需要一个历史值来存放历史最大值，这题有点动态规划的意思

 ]]>
       
         Java
         leetcode
         java
-        stack
-        stack
+        DP
+        DP
       
       
         leetcode
         java
         题解
-        stack
-        min stack
-        最小栈
-        leetcode 155
+        DP
       
   
   
@@ -3464,6 +3254,93 @@ Output: [8,9,9,9,0,0,0,1]
+  
+    Leetcode 20 有效的括号 ( Valid Parentheses *Easy* ) 题解分析
+    /2022/07/02/Leetcode-20-%E6%9C%89%E6%95%88%E7%9A%84%E6%8B%AC%E5%8F%B7-Valid-Parentheses-Easy-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/
+    题目介绍
Given a string s containing just the characters '(', ')', '{', '}', '[' and ']', determine if the input string is valid.

+
An input string is valid if:

+
    
+
  1. Open brackets must be closed by the same type of brackets.
    2. 
+
  2. Open brackets must be closed in the correct order.
    3. 
+

+
示例
Example 1:

+
Input: s = “()”
Output: true  

+

+
Example 2:

+
Input: s = “()[]{}”
Output: true  

+

+
Example 3:

+
Input: s = “(]”
Output: false  

+

+
Constraints:
    
+
  • 1 <= s.length <= 10^4
    • 
+
  • s consists of parentheses only '()[]{}'.
    • 
+

+
解析
easy题，并且看起来也是比较简单的，三种括号按对匹配，直接用栈来做，栈里面存的是括号的类型，如果是左括号，就放入栈中，如果是右括号，就把栈顶的元素弹出，如果弹出的元素不是左括号，就返回false，如果弹出的元素是左括号，就继续往下走，如果遍历完了，如果栈里面还有元素，就返回false，如果遍历完了，如果栈里面没有元素，就返回true

+
代码
class Solution {
+    public boolean isValid(String s) {
+
+        if (s.length() % 2 != 0) {
+            return false;
+        }
+        Stack<String> stk = new Stack<>();
+        for (int i = 0; i < s.length(); i++) {
+            if (s.charAt(i) == '{' || s.charAt(i) == '(' || s.charAt(i) == '[') {
+                stk.push(String.valueOf(s.charAt(i)));
+                continue;
+            }
+            if (s.charAt(i) == '}') {
+                if (stk.isEmpty()) {
+                    return false;
+                }
+                String cur = stk.peek();
+                if (cur.charAt(0) != '{') {
+                    return false;
+                } else {
+                    stk.pop();
+                }
+                continue;
+            }
+            if (s.charAt(i) == ']') {
+                if (stk.isEmpty()) {
+                    return false;
+                }
+                String cur = stk.peek();
+                if (cur.charAt(0) != '[') {
+                    return false;
+                } else {
+                    stk.pop();
+                }
+                continue;
+            }
+            if (s.charAt(i) == ')') {
+                if (stk.isEmpty()) {
+                    return false;
+                }
+                String cur = stk.peek();
+                if (cur.charAt(0) != '(') {
+                    return false;
+                } else {
+                    stk.pop();
+                }
+                continue;
+            }
+
+        }
+        return stk.size() == 0;
+    }
+}

+
+]]>
+      
+        Java
+        leetcode
+      
+      
+        leetcode
+        java
+      
+  
   
     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/
@@ -4294,45 +4171,6 @@ 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/
@@ -4385,6 +4223,45 @@ 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/
@@ -5018,69 +4895,104 @@ public:
       
   
   
-    mybatis 的 foreach 使用的注意点
-    /2022/07/09/mybatis-%E7%9A%84-foreach-%E4%BD%BF%E7%94%A8%E7%9A%84%E6%B3%A8%E6%84%8F%E7%82%B9/
-    mybatis 在作为轻量级 orm 框架，如果要使用类似于 in 查询的语句，除了直接替换字符串，还可以使用 foreach 标签
在mybatis的 dtd 文件中可以看到可以配置这些字段，

-
<!ELEMENT foreach (#PCDATA | include | trim | where | set | foreach | choose | if | bind)*>
-<!ATTLIST foreach
-collection CDATA #REQUIRED
-item CDATA #IMPLIED
-index CDATA #IMPLIED
-open CDATA #IMPLIED
-close CDATA #IMPLIED
-separator CDATA #IMPLIED
->

-
collection 表示需要使用 foreach 的集合，item 表示进行迭代的变量名，index 就是索引值，而 open 跟 close
代表拼接的起始和结束符号，一般就是左右括号，separator 则是每个 item 直接的分隔符

-
例如写了一个简单的 sql 查询

-
<select id="search" parameterType="list" resultMap="StudentMap">
-    select * from student
-    <where>
-        id in
-        <foreach collection="list" item="item" open="(" close=")" separator=",">
-            #{item}
-        </foreach>
-    </where>
-</select>

-
这里就发现了一个问题，collection 对应的这个值，如果传入的参数是个 HashMap，collection 的这个值就是以此作为
 key 从这个 HashMap 获取对应的集合，但是这里有几个特殊的小技巧，
 在上面的这个方法对应的接口方法定义中

-
public List<Student> search(List<Long> userIds);

-
我是这么定义的，而 collection 的值是list，这里就有一点不能理解了，但其实是 mybatis 考虑到使用的方便性，
帮我们做了一点点小转换，我们翻一下 mybatis 的DefaultSqlSession 中的代码可以看到

-
@Override
-public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
-  try {
-    MappedStatement ms = configuration.getMappedStatement(statement);
-    return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
-  } catch (Exception e) {
-    throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
-  } finally {
-    ErrorContext.instance().reset();
-  }
-}
-// 就是在这帮我们做了转换
-  private Object wrapCollection(final Object object) {
-  if (object instanceof Collection) {
-    StrictMap<Object> map = new StrictMap<Object>();
-    map.put("collection", object);
-    if (object instanceof List) {
-      // 如果类型是list 就会转成以 list 为 key 的 map
-      map.put("list", object);
+    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;
     }
-    return map;
-  } else if (object != null && object.getClass().isArray()) {
-    StrictMap<Object> map = new StrictMap<Object>();
-    map.put("array", object);
-    return map;
-  }
-  return object;
-  }
]]>
+
+    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);
+            }
+        }

+
+
核心代码就是下面这段，其实就是帮我们把前面要做的事情做掉了，是不是挺方便的，小记一下哈

+]]>
       
         Java
-        Mybatis
-        Mysql
+        集合
       
       
         Java
-        Mysql
-        Mybatis
+        Stream
+        Comparator
+        排序
+        sort
+        nullsfirst
       
   
   
@@ -5532,6 +5444,72 @@ location ~*openresty
       
   
+  
+    mybatis 的 foreach 使用的注意点
+    /2022/07/09/mybatis-%E7%9A%84-foreach-%E4%BD%BF%E7%94%A8%E7%9A%84%E6%B3%A8%E6%84%8F%E7%82%B9/
+    mybatis 在作为轻量级 orm 框架，如果要使用类似于 in 查询的语句，除了直接替换字符串，还可以使用 foreach 标签
在mybatis的 dtd 文件中可以看到可以配置这些字段，

+
<!ELEMENT foreach (#PCDATA | include | trim | where | set | foreach | choose | if | bind)*>
+<!ATTLIST foreach
+collection CDATA #REQUIRED
+item CDATA #IMPLIED
+index CDATA #IMPLIED
+open CDATA #IMPLIED
+close CDATA #IMPLIED
+separator CDATA #IMPLIED
+>

+
collection 表示需要使用 foreach 的集合，item 表示进行迭代的变量名，index 就是索引值，而 open 跟 close
代表拼接的起始和结束符号，一般就是左右括号，separator 则是每个 item 直接的分隔符

+
例如写了一个简单的 sql 查询

+
<select id="search" parameterType="list" resultMap="StudentMap">
+    select * from student
+    <where>
+        id in
+        <foreach collection="list" item="item" open="(" close=")" separator=",">
+            #{item}
+        </foreach>
+    </where>
+</select>

+
这里就发现了一个问题，collection 对应的这个值，如果传入的参数是个 HashMap，collection 的这个值就是以此作为
 key 从这个 HashMap 获取对应的集合，但是这里有几个特殊的小技巧，
 在上面的这个方法对应的接口方法定义中

+
public List<Student> search(List<Long> userIds);

+
我是这么定义的，而 collection 的值是list，这里就有一点不能理解了，但其实是 mybatis 考虑到使用的方便性，
帮我们做了一点点小转换，我们翻一下 mybatis 的DefaultSqlSession 中的代码可以看到

+
@Override
+public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
+  try {
+    MappedStatement ms = configuration.getMappedStatement(statement);
+    return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
+  } catch (Exception e) {
+    throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
+  } finally {
+    ErrorContext.instance().reset();
+  }
+}
+// 就是在这帮我们做了转换
+  private Object wrapCollection(final Object object) {
+  if (object instanceof Collection) {
+    StrictMap<Object> map = new StrictMap<Object>();
+    map.put("collection", object);
+    if (object instanceof List) {
+      // 如果类型是list 就会转成以 list 为 key 的 map
+      map.put("list", object);
+    }
+    return map;
+  } else if (object != null && object.getClass().isArray()) {
+    StrictMap<Object> map = new StrictMap<Object>();
+    map.put("array", object);
+    return map;
+  }
+  return object;
+  }
]]>
+      
+        Java
+        Mybatis
+        Mysql
+      
+      
+        Java
+        Mysql
+        Mybatis
+      
+  
   
     pcre-intro-and-a-simple-package
     /2015/01/16/pcre-intro-and-a-simple-package/
@@ -5679,6 +5657,47 @@ Starting node rabbit@rabbit2 typedef struct intset {
+    // 编码方式
+    uint32_t encoding;
+    // 集合包含的元素数量
+    uint32_t length;
+    // 保存元素的数组
+    int8_t contents[];
+} intset;
+
+/* Note that these encodings are ordered, so:
+ * INTSET_ENC_INT16 < INTSET_ENC_INT32 < INTSET_ENC_INT64. */
+#define INTSET_ENC_INT16 (sizeof(int16_t))
+#define INTSET_ENC_INT32 (sizeof(int32_t))
+#define INTSET_ENC_INT64 (sizeof(int64_t))

+
一眼看，为啥整型还需要编码，然后 int8_t 怎么能存下大整形呢，带着这些疑问，我们一步步分析下去，这里的编码其实指的是这个整型集合里存的究竟是多大的整型，16 位，还是 32 位，还是 64 位，结构体下面的宏定义就是表示了 encoding 的可能取值，INTSET_ENC_INT16 表示每个元素用2个字节存储，INTSET_ENC_INT32 表示每个元素用4个字节存储，INTSET_ENC_INT64 表示每个元素用8个字节存储。因此，intset中存储的整数最多只能占用64bit。length 就是正常的表示集合中元素的数量。最奇怪的应该就是这个 contents 了，是个 int8_t 的数组，那放毛线数据啊，最小的都有 16 位，这里我在看代码和《redis 设计与实现》的时候也有点懵逼，后来查了下发现这是个比较取巧的用法，这里我用自己的理解表述一下，先看看 8，16，32，64 的关系，一眼看就知道都是 2 的 N 次，并且呈两倍关系，而且 8 位刚好一个字节，所以呢其实这里的contents 不是个常规意义上的 int8_t 类型的数组，而是个柔性数组。看下 wiki 的定义

+

+
Flexible array members1 were introduced in the C99 standard of the C programming language (in particular, in section §6.7.2.1, item 16, page 103).2 It is a member of a struct, which is an array without a given dimension. It must be the last member of such a struct and it must be accompanied by at least one other member, as in the following example:

+

+
struct vectord {
+    size_t len;
+    double arr[]; // the flexible array member must be last
+};

+
在初始化这个 intset 的时候，这个contents数组是不占用空间的，后面的反正用到了申请，那么这里就有一个问题，给出了三种可能的 encoding 值，他们能随便换吗，显然不行，首先在 intset 中数据的存放是有序的，这个有部分原因是方便二分查找，然后存放数据其实随着数据的大小不同会有一个升级的过程，看下图

新创建的intset只有一个header，总共8个字节。其中encoding = 2, length = 0, 类型都是uint32_t，各占 4 字节，添加15, 5两个元素之后，因为它们是比较小的整数，都能使用2个字节表示，所以encoding不变，值还是2，也就是默认的 INTSET_ENC_INT16，当添加32768的时候，它不再能用2个字节来表示了（2个字节能表达的数据范围是-215~215-1，而32768等于215，超出范围了），因此encoding必须升级到INTSET_ENC_INT32（值为4），即用4个字节表示一个元素。在添加每个元素的过程中，intset始终保持从小到大有序。与ziplist类似，intset也是按小端（little endian）模式存储的（参见维基百科词条Endianness）。比如，在上图中intset添加完所有数据之后，表示encoding字段的4个字节应该解释成0x00000004，而第4个数据应该解释成0x00008000 = 32768

+]]>
+      
+        Redis
+        数据结构
+        C
+        源码
+        Redis
+      
+      
+        redis
+        数据结构
+        源码
+      
+  
   
     redis数据结构介绍-第一部分 SDS，链表，字典
     /2019/12/26/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D/
@@ -5726,72 +5745,31 @@ typedef struct list {
 } dictEntry;
 
 typedef struct dictType {
-    unsigned int (*hashFunction)(const void *key);
-    void *(*keyDup)(void *privdata, const void *key);
-    void *(*valDup)(void *privdata, const void *obj);
-    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
-    void (*keyDestructor)(void *privdata, void *key);
-    void (*valDestructor)(void *privdata, void *obj);
-} dictType;
-
-/* This is our hash table structure. Every dictionary has two of this as we
- * implement incremental rehashing, for the old to the new table. */
-typedef struct dictht {
-    dictEntry **table;
-    unsigned long size;
-    unsigned long sizemask;
-    unsigned long used;
-} dictht;
-
-typedef struct dict {
-    dictType *type;
-    void *privdata;
-    dictht ht[2];
-    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
-    int iterators; /* number of iterators currently running */
-} dict;

-
看了下这个 2.2 版本的代码跟最新版的其实也差的不是很多，所以还是照旧用老代码，可以看到上面四个结构体中，其实只有三个是存储数据用的，dictType 是用来放操作函数的，那么三个存放数据的结构体分别是干嘛的，这时候感觉需要一个图来说明比较好，稍等，我去画个图~

这个图看着应该比较清楚这些都是用来干嘛的了，dict 是我们的主体结构，它有一个指向 dictType 的指针，这里面包含了字典的操作函数，然后是一个私有数据指针，接下来是一个 dictht 的数组，包含两个dictht，这个就是用来存数据的了，然后是 rehashidx 表示重哈希的状态，当是-1 的时候表示当前没有重哈希，iterators 表示正在遍历的迭代器的数量。
首先说说为啥需要有两个 dictht，这是因为字典 dict 这个数据结构随着数据量的增减，会需要在中途做扩容或者缩容操作，如果只有一个的话，对它进行扩容缩容时会影响正常的访问和修改操作，或者说保证正常查询，修改的正确性会比较复杂，并且因为需要高效利用空间，不能一下子申请一个非常大的空间来存很少的数据。当 dict 中 dictht 中的数据量超过 size 的时候负载就超过了 1，就需要进行扩容，这里的其实跟 Java 中的 HashMap 比较类似，超过一定的负载之后进行扩容。这里为啥 size 会超过 1 呢，可能有部分不了解这类结构的同学会比较奇怪，其实就是上图中画的，在数据结构中对于散列的冲突有几类解决方法，比如转换成链表，二次散列，找下个空槽等，这里就使用了链表法，或者说拉链法。当一个新元素通过 hashFunction 得出的 key 跟 sizemask 取模之后的值相同了，那就将其放在原来的节点之前，变成链表挂在数组 dictht.table下面，放在原有节点前是考虑到可能会优先访问。
忘了说明下 dictht 跟 dictEntry 的关系了，dictht 就是个哈希表，它里面是个dictEntry 的二维数组，而 dictEntry 是个包含了 key-value 结构之外还有一个 next 指针，因此可以将哈希冲突的以链表的形式保存下来。
在重点说下重哈希，可能同样写 Java 的同学对这个比较有感觉，跟 HashMap 一样，会以 2 的 N 次方进行扩容，那么扩容的方法就会比较简单，每个键重哈希要不就在原来这个槽，要不就在原来的槽加原 dictht.size 的位置；然后是重头戏，具体是怎么做扩容呢，其实这里就把第二个 ht 用上了，其实这两个hashtable 的具体作用有点类似于 jvm 中的两个 survival 区，但是又不全一样，因为 redis 在扩容的时候是采用的渐进式地重哈希，什么叫渐进式的呢，就是它不是像 jvm 那种标记复制的模式直接将一个 eden 区和原来的 survival 区存活的对象复制到另一个 survival 区，而是在每一次添加，删除，查找或者更新操作时，都会额外的帮忙搬运一部分的原 dictht 中的数据，这里会根据 rehashidx 的值来判断，如果是-1 表示并没有在重哈希中，如果是 0 表示开始重哈希了，然后rehashidx 还会随着每次的帮忙搬运往上加，但全部被搬运完成后 rehashidx 又变回了-1，又可以扯到Java 中的 Concurrent HashMap, 他在扩容的时候也使用了类似的操作。

-]]>
-      
-        Redis
-        数据结构
-        C
-        源码
-        Redis
-      
-      
-        redis
-        数据结构
-        源码
-      
-  
-  
-    redis数据结构介绍三-第三部分 整数集合
-    /2020/01/10/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%B8%89/
-    redis中对于 set 其实有两种处理，对于元素均为整型，并且元素数目较少时，使用 intset 作为底层数据结构，否则使用 dict 作为底层数据结构，先看一下代码先

-
typedef struct intset {
-    // 编码方式
-    uint32_t encoding;
-    // 集合包含的元素数量
-    uint32_t length;
-    // 保存元素的数组
-    int8_t contents[];
-} intset;
+    unsigned int (*hashFunction)(const void *key);
+    void *(*keyDup)(void *privdata, const void *key);
+    void *(*valDup)(void *privdata, const void *obj);
+    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
+    void (*keyDestructor)(void *privdata, void *key);
+    void (*valDestructor)(void *privdata, void *obj);
+} dictType;
 
-/* Note that these encodings are ordered, so:
- * INTSET_ENC_INT16 < INTSET_ENC_INT32 < INTSET_ENC_INT64. */
-#define INTSET_ENC_INT16 (sizeof(int16_t))
-#define INTSET_ENC_INT32 (sizeof(int32_t))
-#define INTSET_ENC_INT64 (sizeof(int64_t))

-
一眼看，为啥整型还需要编码，然后 int8_t 怎么能存下大整形呢，带着这些疑问，我们一步步分析下去，这里的编码其实指的是这个整型集合里存的究竟是多大的整型，16 位，还是 32 位，还是 64 位，结构体下面的宏定义就是表示了 encoding 的可能取值，INTSET_ENC_INT16 表示每个元素用2个字节存储，INTSET_ENC_INT32 表示每个元素用4个字节存储，INTSET_ENC_INT64 表示每个元素用8个字节存储。因此，intset中存储的整数最多只能占用64bit。length 就是正常的表示集合中元素的数量。最奇怪的应该就是这个 contents 了，是个 int8_t 的数组，那放毛线数据啊，最小的都有 16 位，这里我在看代码和《redis 设计与实现》的时候也有点懵逼，后来查了下发现这是个比较取巧的用法，这里我用自己的理解表述一下，先看看 8，16，32，64 的关系，一眼看就知道都是 2 的 N 次，并且呈两倍关系，而且 8 位刚好一个字节，所以呢其实这里的contents 不是个常规意义上的 int8_t 类型的数组，而是个柔性数组。看下 wiki 的定义

-

-
Flexible array members1 were introduced in the C99 standard of the C programming language (in particular, in section §6.7.2.1, item 16, page 103).2 It is a member of a struct, which is an array without a given dimension. It must be the last member of such a struct and it must be accompanied by at least one other member, as in the following example:

-

-
struct vectord {
-    size_t len;
-    double arr[]; // the flexible array member must be last
-};

-
在初始化这个 intset 的时候，这个contents数组是不占用空间的，后面的反正用到了申请，那么这里就有一个问题，给出了三种可能的 encoding 值，他们能随便换吗，显然不行，首先在 intset 中数据的存放是有序的，这个有部分原因是方便二分查找，然后存放数据其实随着数据的大小不同会有一个升级的过程，看下图

新创建的intset只有一个header，总共8个字节。其中encoding = 2, length = 0, 类型都是uint32_t，各占 4 字节，添加15, 5两个元素之后，因为它们是比较小的整数，都能使用2个字节表示，所以encoding不变，值还是2，也就是默认的 INTSET_ENC_INT16，当添加32768的时候，它不再能用2个字节来表示了（2个字节能表达的数据范围是-215~215-1，而32768等于215，超出范围了），因此encoding必须升级到INTSET_ENC_INT32（值为4），即用4个字节表示一个元素。在添加每个元素的过程中，intset始终保持从小到大有序。与ziplist类似，intset也是按小端（little endian）模式存储的（参见维基百科词条Endianness）。比如，在上图中intset添加完所有数据之后，表示encoding字段的4个字节应该解释成0x00000004，而第4个数据应该解释成0x00008000 = 32768

+/* This is our hash table structure. Every dictionary has two of this as we
+ * implement incremental rehashing, for the old to the new table. */
+typedef struct dictht {
+    dictEntry **table;
+    unsigned long size;
+    unsigned long sizemask;
+    unsigned long used;
+} dictht;
+
+typedef struct dict {
+    dictType *type;
+    void *privdata;
+    dictht ht[2];
+    int rehashidx; /* rehashing not in progress if rehashidx == -1 */
+    int iterators; /* number of iterators currently running */
+} dict;

+
看了下这个 2.2 版本的代码跟最新版的其实也差的不是很多，所以还是照旧用老代码，可以看到上面四个结构体中，其实只有三个是存储数据用的，dictType 是用来放操作函数的，那么三个存放数据的结构体分别是干嘛的，这时候感觉需要一个图来说明比较好，稍等，我去画个图~

这个图看着应该比较清楚这些都是用来干嘛的了，dict 是我们的主体结构，它有一个指向 dictType 的指针，这里面包含了字典的操作函数，然后是一个私有数据指针，接下来是一个 dictht 的数组，包含两个dictht，这个就是用来存数据的了，然后是 rehashidx 表示重哈希的状态，当是-1 的时候表示当前没有重哈希，iterators 表示正在遍历的迭代器的数量。
首先说说为啥需要有两个 dictht，这是因为字典 dict 这个数据结构随着数据量的增减，会需要在中途做扩容或者缩容操作，如果只有一个的话，对它进行扩容缩容时会影响正常的访问和修改操作，或者说保证正常查询，修改的正确性会比较复杂，并且因为需要高效利用空间，不能一下子申请一个非常大的空间来存很少的数据。当 dict 中 dictht 中的数据量超过 size 的时候负载就超过了 1，就需要进行扩容，这里的其实跟 Java 中的 HashMap 比较类似，超过一定的负载之后进行扩容。这里为啥 size 会超过 1 呢，可能有部分不了解这类结构的同学会比较奇怪，其实就是上图中画的，在数据结构中对于散列的冲突有几类解决方法，比如转换成链表，二次散列，找下个空槽等，这里就使用了链表法，或者说拉链法。当一个新元素通过 hashFunction 得出的 key 跟 sizemask 取模之后的值相同了，那就将其放在原来的节点之前，变成链表挂在数组 dictht.table下面，放在原有节点前是考虑到可能会优先访问。
忘了说明下 dictht 跟 dictEntry 的关系了，dictht 就是个哈希表，它里面是个dictEntry 的二维数组，而 dictEntry 是个包含了 key-value 结构之外还有一个 next 指针，因此可以将哈希冲突的以链表的形式保存下来。
在重点说下重哈希，可能同样写 Java 的同学对这个比较有感觉，跟 HashMap 一样，会以 2 的 N 次方进行扩容，那么扩容的方法就会比较简单，每个键重哈希要不就在原来这个槽，要不就在原来的槽加原 dictht.size 的位置；然后是重头戏，具体是怎么做扩容呢，其实这里就把第二个 ht 用上了，其实这两个hashtable 的具体作用有点类似于 jvm 中的两个 survival 区，但是又不全一样，因为 redis 在扩容的时候是采用的渐进式地重哈希，什么叫渐进式的呢，就是它不是像 jvm 那种标记复制的模式直接将一个 eden 区和原来的 survival 区存活的对象复制到另一个 survival 区，而是在每一次添加，删除，查找或者更新操作时，都会额外的帮忙搬运一部分的原 dictht 中的数据，这里会根据 rehashidx 的值来判断，如果是-1 表示并没有在重哈希中，如果是 0 表示开始重哈希了，然后rehashidx 还会随着每次的帮忙搬运往上加，但全部被搬运完成后 rehashidx 又变回了-1，又可以扯到Java 中的 Concurrent HashMap, 他在扩容的时候也使用了类似的操作。

 ]]>
       
         Redis
@@ -7553,35 +7531,6 @@ for _ in data:
         Spring Event
       
   
-  
-    summary-ranges-228
-    /2016/10/12/summary-ranges-228/
-    problem
Given a sorted integer array without duplicates, return the summary of its ranges.

-
For example, given [0,1,2,4,5,7], return ["0->2","4->5","7"].

-
题解
每一个区间的起点nums[i]加上j是否等于nums[i+j]
参考

-
Code
class Solution {
-public:
-    vector<string> summaryRanges(vector<int>& nums) {
-        int i = 0, j = 1, n;
-        vector<string> res;
-        n = nums.size();
-        while(i < n){
-            j = 1;
-            while(j < n && nums[i+j] - nums[i] == j) j++;
-            res.push_back(j <= 1 ? to_string(nums[i]) : to_string(nums[i]) + "->" + to_string(nums[i + j - 1]));
-            i += j;
-        }
-        return res;
-    }
-};
]]>
-      
-        leetcode
-      
-      
-        leetcode
-        c++
-      
-  
   
     swoole-websocket-test
     /2016/07/13/swoole-websocket-test/
@@ -7723,6 +7672,35 @@ user3:
         小技巧
       
   
+  
+    summary-ranges-228
+    /2016/10/12/summary-ranges-228/
+    problem
Given a sorted integer array without duplicates, return the summary of its ranges.

+
For example, given [0,1,2,4,5,7], return ["0->2","4->5","7"].

+
题解
每一个区间的起点nums[i]加上j是否等于nums[i+j]
参考

+
Code
class Solution {
+public:
+    vector<string> summaryRanges(vector<int>& nums) {
+        int i = 0, j = 1, n;
+        vector<string> res;
+        n = nums.size();
+        while(i < n){
+            j = 1;
+            while(j < n && nums[i+j] - nums[i] == j) j++;
+            res.push_back(j <= 1 ? to_string(nums[i]) : to_string(nums[i]) + "->" + to_string(nums[i + j - 1]));
+            i += j;
+        }
+        return res;
+    }
+};
]]>
+      
+        leetcode
+      
+      
+        leetcode
+        c++
+      
+  
   
     《垃圾回收算法手册读书》笔记之整理算法
     /2021/03/07/%E3%80%8A%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6%E7%AE%97%E6%B3%95%E6%89%8B%E5%86%8C%E8%AF%BB%E4%B9%A6%E3%80%8B%E7%AC%94%E8%AE%B0%E4%B9%8B%E6%95%B4%E7%90%86%E7%AE%97%E6%B3%95/
@@ -7745,26 +7723,12 @@ user3:
         jvm
       
   
-  
-    《长安的荔枝》读后感
-    /2022/07/17/%E3%80%8A%E9%95%BF%E5%AE%89%E7%9A%84%E8%8D%94%E6%9E%9D%E3%80%8B%E8%AF%BB%E5%90%8E%E6%84%9F/
-    断断续续地看完了马伯庸老师的《长安的荔枝》，一开始是看这本书在排行榜排得很高，又是马伯庸的，之前看过他的《古董局中局》，还是很有意思的，而且正好是比较短的，不过前后也拖了蛮久才看完，看完后读了下马老师自己写的后记，就特别有感触。
整个故事是围绕一个上林署监事李善德被委任一项给贵妃送荔枝的差事展开，“长安回望绣成堆，山顶千门次第开，一骑红尘妃子笑，无人知是荔枝来”，以前没细究过这个送荔枝的过程，但是以以前的运输速度和保鲜条件，感觉也不是太现实，所以主人公一开始就以为只是像以往一样是送荔枝干这种，能比较方便运输，不容易变质的，结果发现其实是同僚在坑他，这次是要在贵妃生辰的时候给贵妃送来新鲜的岭南荔枝，用比较时兴的词来说，这就是个送命题啊，鲜荔枝一日色变，两日香变，三日味变，同僚的还有杜甫跟韩承，都觉得老李可以直接写休书了，保全家人，不然就是全家送命，李善德也觉得基本算是判刑了，而且其实是这事被转了几次，最后到老李所在的上林署，主管为了骗他接下这个活还特意在文书上把荔枝鲜的“鲜”字贴住，那会叫做“贴黄”，变成了荔枝“煎”，所以说官场险恶，大家都想把这烫手山芋丢出去，结果丢到了我们老实的老李头上，但是从接到这个通知到贵妃的生辰六月初一还有挺长的时间，其实这个活虽然送命，但是在前期这个“荔枝使”也基本就是类似带着尚方宝剑，御赐黄马褂的职位，随便申请经费，不必像常规的部门费用需要定预算，申请后再层层审批，而是特事特批特办的耍赖做法，所以在这段时间是能够潇洒挥霍一下的。其实可以好好地捞一波给妻女，然后写下和离，在自己死后能让她们过的好一些，但最后还是在杜甫的一番劝导下做出了尝试一番的决定，因为也没其他办法，既是退无可退，何不向前拼死一搏，其实说到这，我觉得看这本书感觉有所收获的第一点，有时候总觉得事情没戏了，想躺平放弃了，但是这样其实这个结果是不会变好的，尝试努力，拼尽全力搏一搏，说不定会有所改观，至少不会变更坏了。

-]]>
-      
-        读后感
-        生活
-      
-      
-        生活
-        读后感
-      
-  
   
     一个 nginx 的简单记忆点
     /2022/08/21/%E4%B8%80%E4%B8%AA-nginx-%E7%9A%84%E7%AE%80%E5%8D%95%E8%AE%B0%E5%BF%86%E7%82%B9/
     上周在处理一个 nginx 配置的时候，发现了一个之前不理解的小点，说一个场景，就是我们一般的处理方式就是一个 ip 端口只能配置一个域名的服务，比如 https://nicksxs.me 对应配置到 127.0.0.1:443，如果我想要把 https://nicksxs.com 也解析到这个服务器，并转发到不同的下游，这里就需要借助所谓的 SNI 的功能

 
Server Name Indication
A more generic solution for running several HTTPS servers on a single IP address is TLS Server Name Indication extension (SNI, RFC 6066), which allows a browser to pass a requested server name during the SSL handshake and, therefore, the server will know which certificate it should use for the connection. SNI is currently supported by most modern browsers, though may not be used by some old or special clients.
来源
机翻一下：在单个 IP 地址上运行多个 HTTPS 服务器的更通用的解决方案是 TLS 服务器名称指示扩展（SNI，RFC 6066），它允许浏览器在 SSL 握手期间传递请求的服务器名称，因此，服务器将知道哪个 它应该用于连接的证书。 目前大多数现代浏览器都支持 SNI，但某些旧的或特殊的客户端可能不使用 SNI。

-
首先我们需要确认 sni 已被支持

在实际的配置中就可以这样

+
首先我们需要确认 sni 已被支持

在实际的配置中就可以这样

 
stream {
   map $ssl_preread_server_name $stream_map {
     nicksxs.me nme;
@@ -7795,16 +7759,17 @@ user3:
       
   
   
-    上次的其他 外行聊国足
-    /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 年前应该有了质的变化，身体素质也越来越好，即使是体育弱国，这么继续走下坡路，半死不活的，不觉得是打了自己的脸么。足球也需要基本功，基本的体能，力量这些，看看现在这些国足运动员的体型，对比下女足，说实话，如果男足这些运动员都练得不错的体脂率，耐力等，成绩即使不好，也不会比现在更差。
纯主观吐槽，勿喷。

+    《长安的荔枝》读后感
+    /2022/07/17/%E3%80%8A%E9%95%BF%E5%AE%89%E7%9A%84%E8%8D%94%E6%9E%9D%E3%80%8B%E8%AF%BB%E5%90%8E%E6%84%9F/
+    断断续续地看完了马伯庸老师的《长安的荔枝》，一开始是看这本书在排行榜排得很高，又是马伯庸的，之前看过他的《古董局中局》，还是很有意思的，而且正好是比较短的，不过前后也拖了蛮久才看完，看完后读了下马老师自己写的后记，就特别有感触。
整个故事是围绕一个上林署监事李善德被委任一项给贵妃送荔枝的差事展开，“长安回望绣成堆，山顶千门次第开，一骑红尘妃子笑，无人知是荔枝来”，以前没细究过这个送荔枝的过程，但是以以前的运输速度和保鲜条件，感觉也不是太现实，所以主人公一开始就以为只是像以往一样是送荔枝干这种，能比较方便运输，不容易变质的，结果发现其实是同僚在坑他，这次是要在贵妃生辰的时候给贵妃送来新鲜的岭南荔枝，用比较时兴的词来说，这就是个送命题啊，鲜荔枝一日色变，两日香变，三日味变，同僚的还有杜甫跟韩承，都觉得老李可以直接写休书了，保全家人，不然就是全家送命，李善德也觉得基本算是判刑了，而且其实是这事被转了几次，最后到老李所在的上林署，主管为了骗他接下这个活还特意在文书上把荔枝鲜的“鲜”字贴住，那会叫做“贴黄”，变成了荔枝“煎”，所以说官场险恶，大家都想把这烫手山芋丢出去，结果丢到了我们老实的老李头上，但是从接到这个通知到贵妃的生辰六月初一还有挺长的时间，其实这个活虽然送命，但是在前期这个“荔枝使”也基本就是类似带着尚方宝剑，御赐黄马褂的职位，随便申请经费，不必像常规的部门费用需要定预算，申请后再层层审批，而是特事特批特办的耍赖做法，所以在这段时间是能够潇洒挥霍一下的。其实可以好好地捞一波给妻女，然后写下和离，在自己死后能让她们过的好一些，但最后还是在杜甫的一番劝导下做出了尝试一番的决定，因为也没其他办法，既是退无可退，何不向前拼死一搏，其实说到这，我觉得看这本书感觉有所收获的第一点，有时候总觉得事情没戏了，想躺平放弃了，但是这样其实这个结果是不会变好的，尝试努力，拼尽全力搏一搏，说不定会有所改观，至少不会变更坏了。

 ]]>
       
+        读后感
         生活
-        运动
       
       
         生活
+        读后感
       
   
   
@@ -7941,25 +7906,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 年奥运等往事的回忆和一些细节的呈现，也让我了解比较多当时所不知道的，特别是汶川地震，那时的我还在读高中，真的是看着电视，作为“猛男”都忍不住泪目了，共和国之殇，多难兴邦，但是这对于当事人来说，都是一场醒不过来的噩梦。
然后是对于足球的热爱，其实光这个就能掰扯很多，因为我不爱足球，只爱篮球，其中原因有的没的也挺多可以说的，但是看了他的书，才能比较深入的了解一个足球迷，对足球，对中国足球，对世界杯，对阿根廷的感情。
接下去还是想能继续坚持下去，加油！

-]]>
-      
-        生活
-        读后感
-        白岩松
-        幸福了吗
-      
-      
-        读后感
-        读书
-        打卡
-        幸福了吗
-        足球
-      
-  
   
     关于公共交通再吐个槽
     /2021/03/21/%E5%85%B3%E4%BA%8E%E5%85%AC%E5%85%B1%E4%BA%A4%E9%80%9A%E5%86%8D%E5%90%90%E4%B8%AA%E6%A7%BD/
@@ -7982,6 +7928,25 @@ 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 年奥运等往事的回忆和一些细节的呈现，也让我了解比较多当时所不知道的，特别是汶川地震，那时的我还在读高中，真的是看着电视，作为“猛男”都忍不住泪目了，共和国之殇，多难兴邦，但是这对于当事人来说，都是一场醒不过来的噩梦。
然后是对于足球的热爱，其实光这个就能掰扯很多，因为我不爱足球，只爱篮球，其中原因有的没的也挺多可以说的，但是看了他的书，才能比较深入的了解一个足球迷，对足球，对中国足球，对世界杯，对阿根廷的感情。
接下去还是想能继续坚持下去，加油！

+]]>
+      
+        生活
+        读后感
+        白岩松
+        幸福了吗
+      
+      
+        读后感
+        读书
+        打卡
+        幸福了吗
+        足球
+      
+  
   
     分享记录一下一个 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/
@@ -8059,6 +8024,19 @@ user3:
         干活
       
   
+  
+    上次的其他 外行聊国足
+    /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/10/18/%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%BA%94/
@@ -8144,114 +8122,36 @@ user3:
 ]]>
       
         生活
-        运动
-        跑步
-      
-      
-        生活
-        运动
-        减肥
-        跑步
-      
-  
-  
-    搬运两个 StackOverflow 上的 Mysql 编码相关的问题解答
-    /2022/01/16/%E6%90%AC%E8%BF%90%E4%B8%A4%E4%B8%AA-StackOverflow-%E4%B8%8A%E7%9A%84-Mysql-%E7%BC%96%E7%A0%81%E7%9B%B8%E5%85%B3%E7%9A%84%E9%97%AE%E9%A2%98%E8%A7%A3%E7%AD%94/
-    Mysql 字符编码和排序规则
这个一直是属于一知半解的状态，知道 utf8 跟 utf8mb4 的区别主要是能不能支持 emoji，但是具体后面配置的排序规则是用来干嘛，或者有什么区别，应该使用哪个，所以在 stackoverflow 上找了下，有两个比较不错的解答，就搬过来并且配合机翻做了点修改

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

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

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

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

-
Key differences

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

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

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

-
Benefits of utf8mb4_unicode_ci over utf8mb4_general_ci

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

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

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

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

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

-
What should you use?

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

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

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

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

-
What the parts mean

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

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

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

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

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

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

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

-
主要区别

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

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

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

-
utf8mb4_unicode_ci 相对于 utf8mb4_general_ci的优势

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

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

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

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

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

-
你应该用什么？

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

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

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

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

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

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

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

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

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

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

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

-

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

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

-

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

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

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

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

-

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

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

-

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

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

-]]>
-      
-        Mysql
+        运动
+        跑步
       
       
-        mysql
-        字符集
-        编码
-        utf8
-        utf8mb4
-        utf8mb4_0900_ai_ci
-        utf8mb4_unicode_ci
-        utf8mb4_general_ci
+        生活
+        运动
+        减肥
+        跑步
       
   
   
-    是何原因竟让两人深夜奔袭十公里
-    /2022/06/05/%E6%98%AF%E4%BD%95%E5%8E%9F%E5%9B%A0%E7%AB%9F%E8%AE%A9%E4%B8%A4%E4%BA%BA%E6%B7%B1%E5%A4%9C%E5%A5%94%E8%A2%AD%E5%8D%81%E5%85%AC%E9%87%8C/
-    偶尔来个标题党，不过也是一次比较神奇的经历
上周五下班后跟 LD 约好去吃牛蛙，某个朋友好像对这类都不太能接受，我以前小时候也不常吃，但是这类其实都是口味比较重，没有那种肉本身的腥味，而且肉质比较特殊，吃过几次以后就有点爱上了，这次刚好是 LD 买的新店开业券，比较优惠（我们俩都是有点勤俭持家的，想着小电驴还有三格电，这家店又有点远，骑车单趟大概要 10 公里左右，有点担心，LD 说应该可以的，就一起骑了过去（跟她轮换着骑电驴和共享单车），结果大概离吃牛蛙的店还有一辆公里的时候，电量就报警了，只有最后一个红色的了，一共是五格，最后一格是红色的，提示我们该充电了，这样子是真的有点慌了，之前开了几个月都是还有一两格电的时候就充电了，没有试验过究竟这最后一格电能开多远，总之先到了再说。
这家牛蛙没想到还挺热闹的，我们到那已经快八点了，还有十几个排队的，有个人还想插队（向来是不惯着这种，一边去），旁边刚好是有些商店就逛了下，就跟常规的商业中心差不多，开业的比较早也算是这一边比较核心的商业综合体了，各种品牌都有，而且还有彩票售卖点的，只是不太理解现在的彩票都是兑图案的，而且要 10 块钱一张，我的概念里还是以前 2 块钱一张的双色球，偶尔能中个五块十块的。排队还剩四五个的时候我们就去门口坐着等了，又等了大概二十分钟才排到我们，靠近我们等的里面的位置，好像好几个小女生在那还叫了外卖奶茶，然后各种拍照，小朋友的生活还是丰富多彩的，我们到了就点了蒜蓉的，没有点传说中紫苏的，菜单上画了 N 个🌶，LD 还是想体验下说下次人多点可以试试，我们俩吃怕太辣了吃不消，口味还是不错的，这家貌似是 LD 闺蜜推荐的，口碑有保证。两个人光吃一个蛙锅就差不多了，本来还想再点个其他的，后面实在吃不下了就没点，吃完还是惯例点了个奶茶，不过是真的不好找，太大了。
本来是就回个家的事了，结果就因为前面铺垫的小电驴已经只有一格电了，标题的深夜奔袭十公里就出现了，这个电驴估计续航也虚标挺严重的，电量也是这样，骑的时候显示只有一格电，关掉再开起来又有三格，然后我们回去骑了没一公里就没电了，这下是真的完球了，觉得车子也比较新，直接停外面也不放心，就开始了深夜的十公里推电驴奔袭，LD 看我太累还帮我中间推了一段，虽然是跑过十公里的，但是推着个没电的电驴，还是着实不容易的，LD 也是陪我推着车走，中间好几次说我们把电驴停着打车回去，把电池带回去充满了明天再过来骑车，可能是心态已经转变了，这应该算是一次很特殊的体验，从我们吃完出来大概十点，到最后我们推到小区，大概是过了两个小时的样子，说句深夜也不太过分，把这次这么推车看成了一种意志力的考验，很多事情也都是怕坚持，或者说怕不能坚持，想走得远，没有持续的努力坚持肯定是不行的，所以还是坚持着把车推回来（好吧，我其实主要是怕车被偷，毕竟刚来杭州上学没多久就被偷了自行车留下了阴影），中间感谢 LD，跟我轮着推了一段路，有些下坡的时候还在那坐着用脚蹬一下，离家里大概还有一公里的时候，有个骑电瓶车的大叔还停下来问我们是车破了还是没电了，应该是出于好意吧，最后快到的时候真的非常渴，买了2.5 升的水被我一口气喝了大半瓶，奶茶已经不能起到解渴的作用了，本来以为这样能消耗很多，结果第二天一称还重了，（我的称一定有问题 233

+    Dubbo 使用的几个记忆点
+    /2022/04/02/Dubbo-%E4%BD%BF%E7%94%A8%E7%9A%84%E5%87%A0%E4%B8%AA%E8%AE%B0%E5%BF%86%E7%82%B9/
+    因为后台使用的 dubbo 作为 rpc 框架，并且会有一些日常使用情景有一些小的技巧，在这里做下记录作笔记用

+
dubbo 只拉取不注册
<dubbo:registry address="zookeeper://127.0.0.1:2181" register="false" />

+
就是只要 register="false" 就可以了，这样比如我们在开发环境想运行服务，但又不想让开发环境正常的请求调用到本地来，当然这不是唯一的方式，通过 dubbo 2.7 以上的 tag 路由也可以实现或者自行改造拉取和注册服务的逻辑，因为注册到注册中心的其实是一串带参数的 url，还是比较方便改造的。相反的就是只注册，不拉取

+
dubbo 只注册不拉取
<dubbo:registry address="zookeeper://127.0.0.1:2181" subscribe="false" />

+
这个使用场景就是如果我这个服务只作为 provider，没有任何调用其他的服务，其实就可以这么设置  

+
权重配置
<dubbo:provider loadbalance="random" weight="50"/>

+
首先这是在使用了随机的负载均衡策略的时候可以进行配置，并且是对于多个 provider 的情况下，这样其实也可以部分解决上面的只拉取不注册的问题，我把自己的权重调成 0 或者很低

 ]]>
       
-        生活
+        Java
+        Dubbo
       
       
-        生活
+        Java
+        Dubbo
+        RPC
+        负载均衡
       
   
   
@@ -8271,17 +8171,90 @@ user3:
       
   
   
-    给小电驴上牌
-    /2022/03/20/%E7%BB%99%E5%B0%8F%E7%94%B5%E9%A9%B4%E4%B8%8A%E7%89%8C/
-    三八节活动的时候下决心买了个小电驴，主要是上下班路上现在通勤条件越来越恶劣了，之前都是觉得坐公交就行了，实际路程就比较短，但是现在或者说大概是年前那两个月差不多就开始了，基本是堵一路，个人感觉是天目山路那边在修地铁，而且蚂蚁的几个空间都在那，上班的时间点都差不多，前一个修地铁感觉挺久了，机动车保有量也越来越多，总体是古墩路就越来越堵，还有个原因就是早上上班的点共享单车都被骑走了，有时候整整走一路都没一辆，有时候孤零零地有一辆基本都是破的；走路其实也是一种选择，但是因为要赶着上班，走得太慢就要很久，可能要 45 分钟这样，走得比较快就一身汗挺难受的。所以考虑自行车和电动车，这里还有一点就是不管是乘公交还是骑共享单车，其实都要从楼下走出去蛮远，公司回来也是，也就是这种通勤方式在准备阶段就花了比较多时间，比如总的从下班到到家的时间是半小时，可能在骑共享单车和公交车上的时间都不到十分钟，就比较难受。觉得这种比例太浪费时间，如果能有这种比较点对点的方式，估计能省时省力不少，前面说的骑共享单车的方式其实在之前是比较可行的，但是后来越来越少车，基本都是每周的前几天，周一到周三都是没有车，走路到公司再冷的天都是走出一身的汗，下雨天就更难受，本来下雨天应该是优先选择坐公交，但是一般下雨天堵车会更严重，而且车子到我上车的那个站，下雨天就挤得不行，总体说下来感觉事情都不打，但是几年下来，还是会挺不爽的。

-
电驴看的比较草率，主要是考虑续航，然后锂电池外加 48v 和 24AH，这样一般来讲还是价格比较高的，只是原来没预料到这个限速，以为现在的车子都比较快，但是现在的新国标车子都是 25km/h 的限速，然后 15km/h 都是会要提醒，虽然说有一些特殊的解除限速的方法，但是解了也就 35km/h ，差距不是特别大，而且现在的车子都是比较小，也不太能载东西，特别是上下班路程也不远的情况下，其实不是那么需要速度，就像我朋友说的，可能骑车的时间还不如等红绿灯多，所以就还好，也不打算解除限速，只是品牌上也仔细看，后来选了绿源，目前大部分还是雅迪，爱玛，台羚，绿源，小牛等，路上看的话还是雅迪比较多，不过价格也比较贵一点，还有就是小牛了，是比较新兴的品牌，手机 App 什么的做得比较好，而且也比较贵，最后以相对比较便宜的价格买了个锂电 48V24AH 的小车子，后来发现还是有点不方便的点就是没有比较大的筐，也不好装，这样就是下雨天雨衣什么的比较不方便放。

-
聊回来主题上牌这个事情，这个事情也是颇费心力，提车的时候店里的让我跟他早上一起去，但是因为不确定时间，也比较远就没跟着去，因为我是线上买的，线下自提，线下的店可能没啥利润可以拿，就不肯帮忙代上牌，朋友说在线下店里买是可以代上的，自己上牌过程也比较曲折，一开始是头盔没到，然后是等开发票，主要的东西就是需要骑着车子去车管所，不能只自己去，然后需要预约，附近比较近的都是提前一周就预约完了号了，要提前在支付宝上进行预约，比较空的就是店里推荐的景区大队，但是随之而来就是比较蛋疼的，这个景区大队太远了，看下骑车距离有十几公里，所以就有点拖延症，但是总归要上的，不然一直不能开是白买了，上牌的材料主要是车辆合格证，发票，然后车子上的浙品码，在车架上和电池上，然后车架号什么的都要跟合格证上完全对应，整体车子要跟合格证上一毛一样，如果有额外的反光镜，后面副座都需要拆掉，脚踏板要装上，到了那其实还比较顺利，就是十几公里外加那天比较冷，吹得头疼。

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

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

+
示例
Example 1:

+
Input
+["MinStack","push","push","push","getMin","pop","top","getMin"]
+[[],[-2],[0],[-3],[],[],[],[]]
+
+Output
+[null,null,null,null,-3,null,0,-2]
+
+Explanation
+MinStack minStack = new MinStack();
+minStack.push(-2);
+minStack.push(0);
+minStack.push(-3);
+minStack.getMin(); // return -3
+minStack.pop();
+minStack.top();    // return 0
+minStack.getMin(); // return -2

+
+
简要分析
其实现在大部分语言都自带类栈的数据结构，Java 也自带 stack 这个数据结构，所以这个题的主要难点的就是常数级的获取最小元素，最开始的想法是就一个栈外加一个记录最小值的变量就行了，但是仔细一想是不行的，因为随着元素被 pop 出去，这个最小值也可能需要梗着变化，就不太好判断了，所以后面是用了一个辅助栈。

+
代码
class MinStack {
+        // 这个作为主栈
+        Stack<Integer> s1 = new Stack<>();
+        // 这个作为辅助栈，放最小值的栈
+        Stack<Integer> s2 = new Stack<>();
+        /** initialize your data structure here. */
+        public MinStack() {
+
+        }
+
+        public void push(int x) {
+            // 放入主栈
+            s1.push(x);
+            // 当 s2 是空或者当前值是小于"等于" s2 栈顶时，压入辅助最小值的栈
+            // 注意这里的"等于"非常必要，因为当最小值有多个的情况下，也需要压入栈，否则在 pop 的时候就会不对等
+            if (s2.isEmpty() || x <= s2.peek()) {
+                s2.push(x);
+            }
+        }
+
+        public void pop() {
+            // 首先就是主栈要 pop，然后就是第二个了，跟上面的"等于"很有关系，
+            // 因为如果有两个最小值，如果前面等于的情况没有压栈，那这边相等的时候 pop 就会少一个了，可能就导致最小值不对了
+            int x = s1.pop();
+            if (x == s2.peek())  {
+                s2.pop();
+            }
+        }
+
+        public int top() {
+            // 栈顶的元素
+            return s1.peek();
+        }
+
+        public int getMin() {
+            // 辅助最小栈的栈顶
+            return s2.peek();
+        }
+    }

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

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

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

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

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

+
Key differences

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

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

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

+
Benefits of utf8mb4_unicode_ci over utf8mb4_general_ci

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

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

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

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

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

+
What should you use?

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

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

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

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

+
What the parts mean

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

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

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

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

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

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

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

+
主要区别

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

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

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

+
utf8mb4_unicode_ci 相对于 utf8mb4_general_ci的优势

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

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

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

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

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

+
你应该用什么？

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

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

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

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

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

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

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

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

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

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

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

+

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

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

+

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

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

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

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

+

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

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

+

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

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

+]]>
+      
+        Mysql
+      
+      
+        mysql
+        字符集
+        编码
+        utf8
+        utf8mb4
+        utf8mb4_0900_ai_ci
+        utf8mb4_unicode_ci
+        utf8mb4_general_ci
+      
+  
   
     聊一下 RocketMQ 的 NameServer 源码
     /2020/07/05/%E8%81%8A%E4%B8%80%E4%B8%8B-RocketMQ-%E7%9A%84-NameServer-%E6%BA%90%E7%A0%81/
@@ -9702,63 +9763,18 @@ user3:
         中间件
         源码解析
         NameServer
-      
-  
-  
-    聊一下 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

-
如上面的图显示的，要在用户态跟内核态进行切换，数据还需要在内核缓冲跟用户缓冲之间拷贝多次，

-

-
    
-
  1. 第一步是调用 read，需要在用户态切换成内核态，DMA模块从磁盘中读取文件，并存储在内核缓冲区，相当于是第一次复制
    2. 
-
  2. 数据从内核缓冲区被拷贝到用户缓冲区，read 调用返回，伴随着内核态又切换成用户态，完成了第二次复制
    3. 
-
  3. 然后是write 写入，这里也会伴随着用户态跟内核态的切换，数据从用户缓冲区被复制到内核空间缓冲区，完成了第三次复制，这次有点不一样的是数据不是在内核缓冲区了，会复制到 socket buffer 中。
    4. 
-
  4. write 系统调用返回，又切换回了用户态，然后数据由 DMA 拷贝到协议引擎。
    5. 
-

-

-
如此就能看出其实默认的读写操作代价是非常大的，而在 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;
-}

+      
+  
+  
+    是何原因竟让两人深夜奔袭十公里
+    /2022/06/05/%E6%98%AF%E4%BD%95%E5%8E%9F%E5%9B%A0%E7%AB%9F%E8%AE%A9%E4%B8%A4%E4%BA%BA%E6%B7%B1%E5%A4%9C%E5%A5%94%E8%A2%AD%E5%8D%81%E5%85%AC%E9%87%8C/
+    偶尔来个标题党，不过也是一次比较神奇的经历
上周五下班后跟 LD 约好去吃牛蛙，某个朋友好像对这类都不太能接受，我以前小时候也不常吃，但是这类其实都是口味比较重，没有那种肉本身的腥味，而且肉质比较特殊，吃过几次以后就有点爱上了，这次刚好是 LD 买的新店开业券，比较优惠（我们俩都是有点勤俭持家的，想着小电驴还有三格电，这家店又有点远，骑车单趟大概要 10 公里左右，有点担心，LD 说应该可以的，就一起骑了过去（跟她轮换着骑电驴和共享单车），结果大概离吃牛蛙的店还有一辆公里的时候，电量就报警了，只有最后一个红色的了，一共是五格，最后一格是红色的，提示我们该充电了，这样子是真的有点慌了，之前开了几个月都是还有一两格电的时候就充电了，没有试验过究竟这最后一格电能开多远，总之先到了再说。
这家牛蛙没想到还挺热闹的，我们到那已经快八点了，还有十几个排队的，有个人还想插队（向来是不惯着这种，一边去），旁边刚好是有些商店就逛了下，就跟常规的商业中心差不多，开业的比较早也算是这一边比较核心的商业综合体了，各种品牌都有，而且还有彩票售卖点的，只是不太理解现在的彩票都是兑图案的，而且要 10 块钱一张，我的概念里还是以前 2 块钱一张的双色球，偶尔能中个五块十块的。排队还剩四五个的时候我们就去门口坐着等了，又等了大概二十分钟才排到我们，靠近我们等的里面的位置，好像好几个小女生在那还叫了外卖奶茶，然后各种拍照，小朋友的生活还是丰富多彩的，我们到了就点了蒜蓉的，没有点传说中紫苏的，菜单上画了 N 个🌶，LD 还是想体验下说下次人多点可以试试，我们俩吃怕太辣了吃不消，口味还是不错的，这家貌似是 LD 闺蜜推荐的，口碑有保证。两个人光吃一个蛙锅就差不多了，本来还想再点个其他的，后面实在吃不下了就没点，吃完还是惯例点了个奶茶，不过是真的不好找，太大了。
本来是就回个家的事了，结果就因为前面铺垫的小电驴已经只有一格电了，标题的深夜奔袭十公里就出现了，这个电驴估计续航也虚标挺严重的，电量也是这样，骑的时候显示只有一格电，关掉再开起来又有三格，然后我们回去骑了没一公里就没电了，这下是真的完球了，觉得车子也比较新，直接停外面也不放心，就开始了深夜的十公里推电驴奔袭，LD 看我太累还帮我中间推了一段，虽然是跑过十公里的，但是推着个没电的电驴，还是着实不容易的，LD 也是陪我推着车走，中间好几次说我们把电驴停着打车回去，把电池带回去充满了明天再过来骑车，可能是心态已经转变了，这应该算是一次很特殊的体验，从我们吃完出来大概十点，到最后我们推到小区，大概是过了两个小时的样子，说句深夜也不太过分，把这次这么推车看成了一种意志力的考验，很多事情也都是怕坚持，或者说怕不能坚持，想走得远，没有持续的努力坚持肯定是不行的，所以还是坚持着把车推回来（好吧，我其实主要是怕车被偷，毕竟刚来杭州上学没多久就被偷了自行车留下了阴影），中间感谢 LD，跟我轮着推了一段路，有些下坡的时候还在那坐着用脚蹬一下，离家里大概还有一公里的时候，有个骑电瓶车的大叔还停下来问我们是车破了还是没电了，应该是出于好意吧，最后快到的时候真的非常渴，买了2.5 升的水被我一口气喝了大半瓶，奶茶已经不能起到解渴的作用了，本来以为这样能消耗很多，结果第二天一称还重了，（我的称一定有问题 233

 ]]>
       
-        MQ
-        RocketMQ
-        消息队列
+        生活
       
       
-        MQ
-        消息队列
-        RocketMQ
+        生活
       
   
   
@@ -10777,296 +10793,88 @@ user3:
         return 1L;
     }
 
-    @Transactional
-    private Long createStudent2() {
-//        Integer t = Integer.valueOf("aaa");
-        return studentManager.createStudent();
-    }
-}

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

-
EdR7oB

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-

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

-
<bean id="master1" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
-          destroy-method="close"
-          p:driverClassName="com.mysql.cj.jdbc.Driver"
-          p:url="${master1.demo.datasource.url}"
-          p:username="${master1.demo.datasource.username}"
-          p:password="${master1.demo.datasource.password}"
-          p:initialSize="5"
-          p:minIdle="1"
-          p:maxActive="10"
-          p:maxWait="60000"
-          p:timeBetweenEvictionRunsMillis="60000"
-          p:minEvictableIdleTimeMillis="300000"
-          p:validationQuery="SELECT 'x'"
-          p:testWhileIdle="true"
-          p:testOnBorrow="false"
-          p:testOnReturn="false"
-          p:poolPreparedStatements="false"
-          p:maxPoolPreparedStatementPerConnectionSize="20"
-          p:connectionProperties="config.decrypt=true"
-          p:filters="stat,config"/>
-
-    <bean id="master2" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
-          destroy-method="close"
-          p:driverClassName="com.mysql.cj.jdbc.Driver"
-          p:url="${master2.demo.datasource.url}"
-          p:username="${master2.demo.datasource.username}"
-          p:password="${master2.demo.datasource.password}"
-          p:initialSize="5"
-          p:minIdle="1"
-          p:maxActive="10"
-          p:maxWait="60000"
-          p:timeBetweenEvictionRunsMillis="60000"
-          p:minEvictableIdleTimeMillis="300000"
-          p:validationQuery="SELECT 'x'"
-          p:testWhileIdle="true"
-          p:testOnBorrow="false"
-          p:testOnReturn="false"
-          p:poolPreparedStatements="false"
-          p:maxPoolPreparedStatementPerConnectionSize="20"
-          p:connectionProperties="config.decrypt=true"
-          p:filters="stat,config"/>
-
-    <bean id="dataSource" class="com.nicksxs.springdemo.config.DynamicDataSource">
-        <property name="targetDataSources">
-            <map key-type="java.lang.String">
-                <!-- master -->
-                <entry key="master1" value-ref="master1"/>
-                <!-- slave -->
-                <entry key="master2" value-ref="master2"/>
-            </map>
-        </property>
-        <property name="defaultTargetDataSource" ref="master1"/>
-    </bean>

-
-
现在就要回到头上，介绍下这个DatabaseContextHolder，这里使用了 ThreadLocal 存放这个 DatabaseType，为啥要用这个是因为前面说的我们想要让接口层面去配置不同的数据源，要把持相互隔离不受影响，就使用了 ThreadLocal，关于它也可以看我前面写的一篇文章聊聊传说中的 ThreadLocal，而 DatabaseType 就是个简单的枚举

-
public class DatabaseContextHolder {
-    public static final ThreadLocal<DatabaseType> databaseTypeThreadLocal = new ThreadLocal<>();
-
-    public static DatabaseType getDatabaseType() {
-        return databaseTypeThreadLocal.get();
-    }
-
-    public static void putDatabaseType(DatabaseType databaseType) {
-        databaseTypeThreadLocal.set(databaseType);
-    }
-
-    public static void clearDatabaseType() {
-        databaseTypeThreadLocal.remove();
-    }
-}
-public enum DatabaseType {
-    MASTER1("master1", "1"),
-    MASTER2("master2", "2");
-
-    private final String name;
-    private final String value;
-
-    DatabaseType(String name, String value) {
-        this.name = name;
-        this.value = value;
-    }
-
-    public String getName() {
-        return name;
-    }
-
-    public String getValue() {
-        return value;
-    }
-
-    public static DatabaseType getDatabaseType(String name) {
-        if (MASTER2.name.equals(name)) {
-            return MASTER2;
-        }
-        return MASTER1;
-    }
-}

-
-
这边可以看到就是通过动态地通过putDatabaseType设置lookupKey来进行数据源切换，要通过接口注解配置来进行设置的话，我们就需要一个注解

-
@Retention(RetentionPolicy.RUNTIME)
-@Target(ElementType.METHOD)
-public @interface DataSource {
-    String value();
-}

-
-
这个注解可以配置在我的接口方法上，比如这样

-
public interface StudentService {
-
-    @DataSource("master1")
-    public Student queryOne();
-
-    @DataSource("master2")
-    public Student queryAnother();
-
-}

-
-
通过切面来进行数据源的设置

-
@Aspect
-@Component
-@Order(-1)
-public class DataSourceAspect {
-
-    @Pointcut("execution(* com.nicksxs.springdemo.service..*.*(..))")
-    public void pointCut() {
-
-    }
-
+    @Transactional
+    private Long createStudent2() {
+//        Integer t = Integer.valueOf("aaa");
+        return studentManager.createStudent();
+    }
+}

 
-    @Before("pointCut()")
-    public void before(JoinPoint point)
-    {
-        Object target = point.getTarget();
-        System.out.println(target.toString());
-        String method = point.getSignature().getName();
-        System.out.println(method);
-        Class<?>[] classz = target.getClass().getInterfaces();
-        Class<?>[] parameterTypes = ((MethodSignature) point.getSignature())
-                .getMethod().getParameterTypes();
-        try {
-            Method m = classz[0].getMethod(method, parameterTypes);
-            System.out.println("method"+ m.getName());
-            if (m.isAnnotationPresent(DataSource.class)) {
-                DataSource data = m.getAnnotation(DataSource.class);
-                System.out.println("dataSource："+data.value());
-                DatabaseContextHolder.putDatabaseType(DatabaseType.getDatabaseType(data.value()));
-            }
+
第一个公有方法 createStudent 首先调用了 manager 层的创建方法，然后再通过引入的 studentService 调用了createStudent2，我们先跑一下看看会出现啥情况，果不其然报错了，正是这个报错让我纠结了很久

+
EdR7oB

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

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

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

 
-        } catch (Exception e) {
-            e.printStackTrace();
-        }
-    }
 
-    @After("pointCut()")
-    public void after() {
-				DatabaseContextHolder.clearDatabaseType();
-    }
-}

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

-
这是我 master1 的数据，

-

-
master2 的数据

-

-
然后跑一下简单的 demo，

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

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

 
@Override
-public void run(String...args) {
-	LOGGER.info("run here");
-	System.out.println(studentService.queryOne());
-	System.out.println(studentService.queryAnother());
+public Object postProcessAfterInitialization(@Nullable Object bean, String beanName) {
+	if (bean != null) {
+		Object cacheKey = getCacheKey(bean.getClass(), beanName);
+		if (this.earlyProxyReferences.remove(cacheKey) != bean) {
+			return wrapIfNecessary(bean, beanName, cacheKey);
+		}
+	}
+	return bean;
+}

 
-}

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

+
protected Object getCacheKey(Class<?> beanClass, @Nullable String beanName) {
+		if (StringUtils.hasLength(beanName)) {
+			return (FactoryBean.class.isAssignableFrom(beanClass) ?
+					BeanFactory.FACTORY_BEAN_PREFIX + beanName : beanName);
+		}
+		else {
+			return beanClass;
+		}
+	}
 
-
看一下运行结果

-

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

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

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

 ]]>
       
         Java
@@ -11076,8 +10884,8 @@ user3:
         Java
         Spring
         SpringBoot
-        Druid
-        数据源动态切换
+        cglib
+        事务
       
   
   
@@ -11129,6 +10937,20 @@ app.setWebAp
         AutoConfiguration
       
   
+  
+    给小电驴上牌
+    /2022/03/20/%E7%BB%99%E5%B0%8F%E7%94%B5%E9%A9%B4%E4%B8%8A%E7%89%8C/
+    三八节活动的时候下决心买了个小电驴，主要是上下班路上现在通勤条件越来越恶劣了，之前都是觉得坐公交就行了，实际路程就比较短，但是现在或者说大概是年前那两个月差不多就开始了，基本是堵一路，个人感觉是天目山路那边在修地铁，而且蚂蚁的几个空间都在那，上班的时间点都差不多，前一个修地铁感觉挺久了，机动车保有量也越来越多，总体是古墩路就越来越堵，还有个原因就是早上上班的点共享单车都被骑走了，有时候整整走一路都没一辆，有时候孤零零地有一辆基本都是破的；走路其实也是一种选择，但是因为要赶着上班，走得太慢就要很久，可能要 45 分钟这样，走得比较快就一身汗挺难受的。所以考虑自行车和电动车，这里还有一点就是不管是乘公交还是骑共享单车，其实都要从楼下走出去蛮远，公司回来也是，也就是这种通勤方式在准备阶段就花了比较多时间，比如总的从下班到到家的时间是半小时，可能在骑共享单车和公交车上的时间都不到十分钟，就比较难受。觉得这种比例太浪费时间，如果能有这种比较点对点的方式，估计能省时省力不少，前面说的骑共享单车的方式其实在之前是比较可行的，但是后来越来越少车，基本都是每周的前几天，周一到周三都是没有车，走路到公司再冷的天都是走出一身的汗，下雨天就更难受，本来下雨天应该是优先选择坐公交，但是一般下雨天堵车会更严重，而且车子到我上车的那个站，下雨天就挤得不行，总体说下来感觉事情都不打，但是几年下来，还是会挺不爽的。

+
电驴看的比较草率，主要是考虑续航，然后锂电池外加 48v 和 24AH，这样一般来讲还是价格比较高的，只是原来没预料到这个限速，以为现在的车子都比较快，但是现在的新国标车子都是 25km/h 的限速，然后 15km/h 都是会要提醒，虽然说有一些特殊的解除限速的方法，但是解了也就 35km/h ，差距不是特别大，而且现在的车子都是比较小，也不太能载东西，特别是上下班路程也不远的情况下，其实不是那么需要速度，就像我朋友说的，可能骑车的时间还不如等红绿灯多，所以就还好，也不打算解除限速，只是品牌上也仔细看，后来选了绿源，目前大部分还是雅迪，爱玛，台羚，绿源，小牛等，路上看的话还是雅迪比较多，不过价格也比较贵一点，还有就是小牛了，是比较新兴的品牌，手机 App 什么的做得比较好，而且也比较贵，最后以相对比较便宜的价格买了个锂电 48V24AH 的小车子，后来发现还是有点不方便的点就是没有比较大的筐，也不好装，这样就是下雨天雨衣什么的比较不方便放。

+
聊回来主题上牌这个事情，这个事情也是颇费心力，提车的时候店里的让我跟他早上一起去，但是因为不确定时间，也比较远就没跟着去，因为我是线上买的，线下自提，线下的店可能没啥利润可以拿，就不肯帮忙代上牌，朋友说在线下店里买是可以代上的，自己上牌过程也比较曲折，一开始是头盔没到，然后是等开发票，主要的东西就是需要骑着车子去车管所，不能只自己去，然后需要预约，附近比较近的都是提前一周就预约完了号了，要提前在支付宝上进行预约，比较空的就是店里推荐的景区大队，但是随之而来就是比较蛋疼的，这个景区大队太远了，看下骑车距离有十几公里，所以就有点拖延症，但是总归要上的，不然一直不能开是白买了，上牌的材料主要是车辆合格证，发票，然后车子上的浙品码，在车架上和电池上，然后车架号什么的都要跟合格证上完全对应，整体车子要跟合格证上一毛一样，如果有额外的反光镜，后面副座都需要拆掉，脚踏板要装上，到了那其实还比较顺利，就是十几公里外加那天比较冷，吹得头疼。

+]]>
+      
+        生活
+      
+      
+        生活
+      
+  
   
     聊在东京奥运会闭幕式这天-二
     /2021/08/19/%E8%81%8A%E5%9C%A8%E4%B8%9C%E4%BA%AC%E5%A5%A5%E8%BF%90%E4%BC%9A%E9%97%AD%E5%B9%95%E5%BC%8F%E8%BF%99%E5%A4%A9-%E4%BA%8C/
@@ -12846,8 +12668,8 @@ JNI global references: = result Broker
       
   
-  
-    聊聊 Sharding-Jdbc 分库分表下的分页方案
-    /2022/01/09/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E5%88%86%E5%BA%93%E5%88%86%E8%A1%A8%E4%B8%8B%E7%9A%84%E5%88%86%E9%A1%B5%E6%96%B9%E6%A1%88/
-    前面在聊 Sharding-Jdbc 的时候看到了一篇文章，关于一个分页的查询，一直比较直接的想法就是分库分表下的分页是非常不合理的，一般我们的实操方案都是分表加上 ES 搜索做分页，或者通过合表读写分离的方案，因为对于 sharding-jdbc 如果没有带分表键，查询基本都是只能在所有分表都执行一遍，然后再加上分页，基本上是分页越大后续的查询越耗资源，但是仔细的去想这个细节还是这次，就简单说说
首先就是我的分表结构

-
CREATE TABLE `student_time_0` (
-  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
-  `user_id` int(11) NOT NULL,
-  `name` varchar(200) COLLATE utf8_bin DEFAULT NULL,
-  `age` tinyint(3) unsigned DEFAULT NULL,
-  `create_time` bigint(20) DEFAULT NULL,
-  PRIMARY KEY (`id`)
-) ENGINE=InnoDB AUTO_INCREMENT=674 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

-
有这样的三个表，student_time_0, student_time_1, student_time_2, 以 user_id 作为分表键，根据表数量取模作为分表依据
这里先构造点数据，

-
insert into student_time (`name`, `user_id`, `age`, `create_time`) values (?, ?, ?, ?)

-
主要是为了保证 create_time 唯一比较好说明问题，

-
int i = 0;
-try (
-        Connection conn = dataSource.getConnection();
-        PreparedStatement ps = conn.prepareStatement(insertSql)) {
-    do {
-        ps.setString(1, localName + new Random().nextInt(100));
-        ps.setLong(2, 10086L + (new Random().nextInt(100)));
-        ps.setInt(3, 18);
-        ps.setLong(4, new Date().getTime());
-
-
-        int result = ps.executeUpdate();
-        LOGGER.info("current execute result: {}", result);
-        Thread.sleep(new Random().nextInt(100));
-        i++;
-    } while (i <= 2000);

-
三个表的数据分别是 673，678，650，说明符合预期了，各个表数据不一样，接下来比如我们想要做一个这样的分页查询

-
select * from student_time ORDER BY create_time ASC limit 1000, 5;

-
student_time 对于我们使用的 sharding-jdbc 来说当然是逻辑表，首先从一无所知去想这个查询如果我们自己来处理应该是怎么做，
首先是不是可以每个表都从 333 开始取 5 条数据，类似于下面的查询，然后进行 15 条的合并重排序获取前面的 5 条

-
select * from student_time_0 ORDER BY create_time ASC limit 333, 5;
-select * from student_time_1 ORDER BY create_time ASC limit 333, 5;
-select * from student_time_2 ORDER BY create_time ASC limit 333, 5;

-
忽略前面 limit 差的 1，这个结果除非三个表的分布是绝对的均匀，否则结果肯定会出现一定的偏差，以为每个表的 333 这个位置对于其他表来说都不一定是一样的，这样对于最后整体的结果，就会出现偏差
因为一直在纠结怎么让这个更直观的表现出来，所以尝试画了个图

黑色的框代表我从每个表里按排序从 334 到 338 的 5 条数据， 他们在每个表里都是代表了各自正确的排序值，但是对于我们想要的其实是合表后的 1001，1005 这五条，然后我们假设总的排序值位于前 1000 的分布是第 0 个表是 320 条，第 1 个表是 340 条，第 2 个表是 340 条，那么可以明显地看出来我这么查的结果简单合并肯定是不对的。
那么 sharding-jdbc 是如何保证这个结果的呢，其实就是我在每个表里都查分页偏移量和分页大小那么多的数据，在我这个例子里就是对于 0，1，2 三个分表每个都查 1005 条数据，即使我的数据不平衡到最极端的情况，前 1005 条数据都出在某个分表中，也可以正确获得最后的结果，但是明显的问题就是大分页，数据较多，就会导致非常大的问题，即使如 sharding-jdbc 对于合并排序的优化做得比较好，也还是需要传输那么大量的数据，并且查询也耗时，那么有没有解决方案呢，应该说有两个，或者说主要是想讲后者
第一个办法是像这种查询，如果业务上不需要进行跳页，而是只给下一页，那么我们就能把前一次的最大偏移量的 create_time 记录下来，下一页就可以拿着这个偏移量进行查询，这个比较简单易懂，就不多说了
第二个办法是看的58 沈剑的一篇文章，尝试理解讲述一下，
这个办法的第一步跟前面那个错误的方法或者说不准确的方法一样，先是将分页偏移量平均后在三个表里进行查询

-
t0
-334 10158 nick95  18  1641548941767
-335 10098 nick11  18  1641548941879
-336 10167 nick51  18  1641548942089
-337 10167 nick3 18  1641548942119
-338 10170 nick57  18  1641548942169
-
-
-t1
-334 10105 nick98  18  1641548939071   最小
-335 10174 nick94  18  1641548939377
-336 10129 nick85  18  1641548939442
-337 10141 nick84  18  1641548939480
-338 10096 nick74  18  1641548939668
-
-t2
-334 10184 nick11  18  1641548945075
-335 10109 nick93  18  1641548945382
-336 10181 nick41  18  1641548945583
-337 10130 nick80  18  1641548945993
-338 10184 nick19  18  1641548946294  最大

-
然后要做什么呢，其实目标比较明白，因为前面那种方法其实就是我知道了前一页的偏移量，所以可以直接当做条件来进行查询，那这里我也想着拿到这个条件，所以我将第一遍查出来的最小的 create_time 和最大的 create_time 找出来，然后再去三个表里查询，其实主要是最小值，因为我拿着最小值去查以后我就能知道这个最小值在每个表里处在什么位置，

-
t0
-322 10161 nick81  18  1641548939284
-323 10113 nick16  18  1641548939393
-324 10110 nick56  18  1641548939577
-325 10116 nick69  18  1641548939588
-326 10173 nick51  18  1641548939646
-
-t1
-334 10105 nick98  18  1641548939071
-335 10174 nick94  18  1641548939377
-336 10129 nick85  18  1641548939442
-337 10141 nick84  18  1641548939480
-338 10096 nick74  18  1641548939668
-
-t2
-297 10136 nick28  18  1641548939161
-298 10142 nick68  18  1641548939177
-299 10124 nick41  18  1641548939237
-300 10148 nick87  18  1641548939510
-301 10169 nick23  18  1641548939715

-
我只贴了前五条数据，为了方便知道偏移量，每个分表都使用了自增主键，我们可以看到前一次查询的最小值分别在其他两个表里的位置分别是 322-1 和 297-1，那么对于总体来说这个时间应该是在 322 - 1 + 333 + 297 - 1 = 951，那这样子我只要对后面的数据最多每个表查 1000 - 951 + 5 = 54 条数据再进行合并排序就可以获得最终正确的结果。
这个就是传说中的二次查询法。

-]]>
-      
-        Java
-      
-      
-        Java
-        Sharding-Jdbc
-      
-  
   
     聊聊 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/
@@ -13562,36 +13294,7 @@ t2
             e.printStackTrace();
         }
     }
-

看下查询结果

-]]> - - Java - - - Java - Sharding-Jdbc - - - - 聊聊 Sharding-Jdbc 的简单原理初篇 - /2021/12/26/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E7%9A%84%E7%AE%80%E5%8D%95%E5%8E%9F%E7%90%86%E5%88%9D%E7%AF%87/ - 在上一篇 sharding-jdbc 的介绍中其实碰到过一个问题，这里也引出了一个比较有意思的话题
就是我在执行 query 的时候犯过一个比较难发现的错误，

-
ResultSet resultSet = ps.executeQuery(sql);
-

实际上应该是

-
ResultSet resultSet = ps.executeQuery();
-

而这里的差别就是，是否传 sql 这个参数，首先我们要知道这个 ps 是什么，它也是个接口java.sql.PreparedStatement,而真正的实现类是org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement,我们来看下继承关系

这里可以看到继承关系里有org.apache.shardingsphere.driver.jdbc.unsupported.AbstractUnsupportedOperationPreparedStatement
那么在我上面的写错的代码里

-
@Override
-public final ResultSet executeQuery(final String sql) throws SQLException {
-    throw new SQLFeatureNotSupportedException("executeQuery with SQL for PreparedStatement");
-}
-

这个报错一开始让我有点懵，后来点进去了发现是这么个异常，但是我其实一开始是用的更新语句，以为更新不支持，因为平时使用没有深究过，以为是不是需要使用 Mybatis 才可以执行更新，但是理论上也不应该，再往上看原来这些异常是由 sharding-jdbc 包装的，也就是在上面说的AbstractUnsupportedOperationPreparedStatement，这其实也是一种设计思想，本身 jdbc 提供了一系列接口，由各家去支持，包括 mysql，sql server，oracle 等，而正因为这个设计，所以 sharding-jdbc 也可以在此基础上进行设计，我们可以总体地看下 sharding-jdbc 的实现基础

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

在前一篇的 demo 中的

-
Connection conn = dataSource.getConnection();
-

其实就获得了org.apache.shardingsphere.driver.jdbc.core.connection.ShardingSphereConnection#ShardingSphereConnection
然后获得java.sql.PreparedStatement

-
PreparedStatement ps = conn.prepareStatement(sql)
-

就是获取了org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement
然后就是执行

-
ResultSet resultSet = ps.executeQuery();
-

然后获得结果
org.apache.shardingsphere.driver.jdbc.core.resultset.ShardingSphereResultSet

-

其实像 mybatis 也是基于这样去实现的

+

看下查询结果

]]> Java @@ -13601,6 +13304,63 @@ t2 Sharding-Jdbc + + 聊一下 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

+

如上面的图显示的，要在用户态跟内核态进行切换，数据还需要在内核缓冲跟用户缓冲之间拷贝多次，

+
+
    +
  1. 第一步是调用 read，需要在用户态切换成内核态，DMA模块从磁盘中读取文件，并存储在内核缓冲区，相当于是第一次复制
    2. +
  2. 数据从内核缓冲区被拷贝到用户缓冲区，read 调用返回，伴随着内核态又切换成用户态，完成了第二次复制
    3. +
  3. 然后是write 写入，这里也会伴随着用户态跟内核态的切换，数据从用户缓冲区被复制到内核空间缓冲区，完成了第三次复制，这次有点不一样的是数据不是在内核缓冲区了，会复制到 socket buffer 中。
    4. +
  4. write 系统调用返回，又切换回了用户态，然后数据由 DMA 拷贝到协议引擎。
    5. +
+
+

如此就能看出其实默认的读写操作代价是非常大的，而在 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 + + 聊聊 dubbo 的线程池 /2021/04/04/%E8%81%8A%E8%81%8A-dubbo-%E7%9A%84%E7%BA%BF%E7%A8%8B%E6%B1%A0/ @@ -14625,6 +14385,96 @@ $ 3PC + + 聊聊 Sharding-Jdbc 分库分表下的分页方案 + /2022/01/09/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E5%88%86%E5%BA%93%E5%88%86%E8%A1%A8%E4%B8%8B%E7%9A%84%E5%88%86%E9%A1%B5%E6%96%B9%E6%A1%88/ + 前面在聊 Sharding-Jdbc 的时候看到了一篇文章，关于一个分页的查询，一直比较直接的想法就是分库分表下的分页是非常不合理的，一般我们的实操方案都是分表加上 ES 搜索做分页，或者通过合表读写分离的方案，因为对于 sharding-jdbc 如果没有带分表键，查询基本都是只能在所有分表都执行一遍，然后再加上分页，基本上是分页越大后续的查询越耗资源，但是仔细的去想这个细节还是这次，就简单说说
首先就是我的分表结构

+
CREATE TABLE `student_time_0` (
+  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
+  `user_id` int(11) NOT NULL,
+  `name` varchar(200) COLLATE utf8_bin DEFAULT NULL,
+  `age` tinyint(3) unsigned DEFAULT NULL,
+  `create_time` bigint(20) DEFAULT NULL,
+  PRIMARY KEY (`id`)
+) ENGINE=InnoDB AUTO_INCREMENT=674 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
+

有这样的三个表，student_time_0, student_time_1, student_time_2, 以 user_id 作为分表键，根据表数量取模作为分表依据
这里先构造点数据，

+
insert into student_time (`name`, `user_id`, `age`, `create_time`) values (?, ?, ?, ?)
+

主要是为了保证 create_time 唯一比较好说明问题，

+
int i = 0;
+try (
+        Connection conn = dataSource.getConnection();
+        PreparedStatement ps = conn.prepareStatement(insertSql)) {
+    do {
+        ps.setString(1, localName + new Random().nextInt(100));
+        ps.setLong(2, 10086L + (new Random().nextInt(100)));
+        ps.setInt(3, 18);
+        ps.setLong(4, new Date().getTime());
+
+
+        int result = ps.executeUpdate();
+        LOGGER.info("current execute result: {}", result);
+        Thread.sleep(new Random().nextInt(100));
+        i++;
+    } while (i <= 2000);
+

三个表的数据分别是 673，678，650，说明符合预期了，各个表数据不一样，接下来比如我们想要做一个这样的分页查询

+
select * from student_time ORDER BY create_time ASC limit 1000, 5;
+

student_time 对于我们使用的 sharding-jdbc 来说当然是逻辑表，首先从一无所知去想这个查询如果我们自己来处理应该是怎么做，
首先是不是可以每个表都从 333 开始取 5 条数据，类似于下面的查询，然后进行 15 条的合并重排序获取前面的 5 条

+
select * from student_time_0 ORDER BY create_time ASC limit 333, 5;
+select * from student_time_1 ORDER BY create_time ASC limit 333, 5;
+select * from student_time_2 ORDER BY create_time ASC limit 333, 5;
+

忽略前面 limit 差的 1，这个结果除非三个表的分布是绝对的均匀，否则结果肯定会出现一定的偏差，以为每个表的 333 这个位置对于其他表来说都不一定是一样的，这样对于最后整体的结果，就会出现偏差
因为一直在纠结怎么让这个更直观的表现出来，所以尝试画了个图

黑色的框代表我从每个表里按排序从 334 到 338 的 5 条数据， 他们在每个表里都是代表了各自正确的排序值，但是对于我们想要的其实是合表后的 1001，1005 这五条，然后我们假设总的排序值位于前 1000 的分布是第 0 个表是 320 条，第 1 个表是 340 条，第 2 个表是 340 条，那么可以明显地看出来我这么查的结果简单合并肯定是不对的。
那么 sharding-jdbc 是如何保证这个结果的呢，其实就是我在每个表里都查分页偏移量和分页大小那么多的数据，在我这个例子里就是对于 0，1，2 三个分表每个都查 1005 条数据，即使我的数据不平衡到最极端的情况，前 1005 条数据都出在某个分表中，也可以正确获得最后的结果，但是明显的问题就是大分页，数据较多，就会导致非常大的问题，即使如 sharding-jdbc 对于合并排序的优化做得比较好，也还是需要传输那么大量的数据，并且查询也耗时，那么有没有解决方案呢，应该说有两个，或者说主要是想讲后者
第一个办法是像这种查询，如果业务上不需要进行跳页，而是只给下一页，那么我们就能把前一次的最大偏移量的 create_time 记录下来，下一页就可以拿着这个偏移量进行查询，这个比较简单易懂，就不多说了
第二个办法是看的58 沈剑的一篇文章，尝试理解讲述一下，
这个办法的第一步跟前面那个错误的方法或者说不准确的方法一样，先是将分页偏移量平均后在三个表里进行查询

+
t0
+334 10158 nick95  18  1641548941767
+335 10098 nick11  18  1641548941879
+336 10167 nick51  18  1641548942089
+337 10167 nick3 18  1641548942119
+338 10170 nick57  18  1641548942169
+
+
+t1
+334 10105 nick98  18  1641548939071   最小
+335 10174 nick94  18  1641548939377
+336 10129 nick85  18  1641548939442
+337 10141 nick84  18  1641548939480
+338 10096 nick74  18  1641548939668
+
+t2
+334 10184 nick11  18  1641548945075
+335 10109 nick93  18  1641548945382
+336 10181 nick41  18  1641548945583
+337 10130 nick80  18  1641548945993
+338 10184 nick19  18  1641548946294  最大
+

然后要做什么呢，其实目标比较明白，因为前面那种方法其实就是我知道了前一页的偏移量，所以可以直接当做条件来进行查询，那这里我也想着拿到这个条件，所以我将第一遍查出来的最小的 create_time 和最大的 create_time 找出来，然后再去三个表里查询，其实主要是最小值，因为我拿着最小值去查以后我就能知道这个最小值在每个表里处在什么位置，

+
t0
+322 10161 nick81  18  1641548939284
+323 10113 nick16  18  1641548939393
+324 10110 nick56  18  1641548939577
+325 10116 nick69  18  1641548939588
+326 10173 nick51  18  1641548939646
+
+t1
+334 10105 nick98  18  1641548939071
+335 10174 nick94  18  1641548939377
+336 10129 nick85  18  1641548939442
+337 10141 nick84  18  1641548939480
+338 10096 nick74  18  1641548939668
+
+t2
+297 10136 nick28  18  1641548939161
+298 10142 nick68  18  1641548939177
+299 10124 nick41  18  1641548939237
+300 10148 nick87  18  1641548939510
+301 10169 nick23  18  1641548939715
+

我只贴了前五条数据，为了方便知道偏移量，每个分表都使用了自增主键，我们可以看到前一次查询的最小值分别在其他两个表里的位置分别是 322-1 和 297-1，那么对于总体来说这个时间应该是在 322 - 1 + 333 + 297 - 1 = 951，那这样子我只要对后面的数据最多每个表查 1000 - 951 + 5 = 54 条数据再进行合并排序就可以获得最终正确的结果。
这个就是传说中的二次查询法。

+]]> + + Java + + + Java + Sharding-Jdbc + + 聊聊我的远程工作体验 /2022/06/26/%E8%81%8A%E8%81%8A%E6%88%91%E7%9A%84%E8%BF%9C%E7%A8%8B%E5%B7%A5%E4%BD%9C%E4%BD%93%E9%AA%8C/ @@ -14657,20 +14507,6 @@ $ 骑车 - - 聊聊最近平淡的生活之《花束般的恋爱》观后感 - /2021/12/31/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E3%80%8A%E8%8A%B1%E6%9D%9F%E8%88%AC%E7%9A%84%E6%81%8B%E7%88%B1%E3%80%8B%E8%A7%82%E5%90%8E%E6%84%9F/ - 周末在领导的提议下看了豆瓣的年度榜单，本来感觉没啥心情看的，看到主演有有村架纯就觉得可以看一下，颜值即正义嘛，男主小麦跟女主小娟（后面简称小麦跟小娟）是两个在一次非常偶然的没赶上地铁末班车事件中相识，这里得说下日本这种通宵营业的店好像挺不错的，看着也挺正常，国内估计只有酒吧之类的可以。晚上去的地方是有点暗暗的，好像也有点类似酒吧，旁边有类似于 dj 那种，然后同桌的还有除了男女主的另外一对男女，也是因为没赶上地铁末班车的，但也是陌生人，然后小麦突然看到了有个非常有名的电影人，小娟竟然也认识，然后旁边那对完全不认识，还在那吹自己看过很多电影，比如《肖申克的救赎》，于是男女主都特别鄙夷地看着他们，然后他们又去了另一个有点像泡澡的地方席地而坐，他们发现了自己的鞋子都是一样的，然后在女的去上厕所的时候，小麦暗恋的学姐也来了，然后小麦就去跟学姐他们一起坐了，小娟回来后有点不开心就说去朋友家睡，幸好小麦看出来了（他竟然看出来了，本来以为应该是没填过恋爱很木讷的），就追出去，然后就去了小麦家，到了家小娟发现小麦家的书柜上的书简直就跟她自己家的一模一样，小麦还给小娟吹了头发，一起吃烤饭团，看电影，第二天送小娟上了公交，还约好了一起看木乃伊展，然而并没有交换联系方式，但是他们还是约上了一起看了木乃伊展，在餐馆就出现了片头那一幕的来源，因为餐馆他们想一起听歌，就用有线耳机一人一个耳朵听，但是旁边就有个大叔说“你们是不是不爱音乐，左右耳朵是不一样的，只有一起听才是真正的音乐”这样的话，然后的剧情有点跳，因为是指他们一直在这家餐馆吃饭，中间有他们一起出去玩情节穿插着，也是在这他们确立了关系，可以说主体就是体现了他们非常的合拍和默契，就像一些影评说的，这部电影是说如何跟百分百合拍的人分手，然后就是正常的恋爱开始啪啪啪，一直腻在床上，也没去就业说明会，后面也有讲了一点小麦带着小娟去认识他的朋友，也把小娟介绍给了他们认识，这里算是个小伏笔，后面他们分手也有这里的人的一些关系，接下去的剧情说实话我是不太喜欢的，如果一部八分的电影只是说恋爱被现实打败的话，我觉得在我这是不合格的，但是事实也是这样，小麦其实是有家里的资助，所以后面还是按自己的喜好给一些机构画点插画，小娟则要出去工作，因为小娟家庭观念也是要让她出去有正经工作，用脚指头想也能知道肯定不顺利，然后就是暂时在一家蛋糕店工作，小麦就每天去接小娟，日子过得甜甜蜜蜜，后面小娟在自己的努力下考了个什么资格证，去了一家医院还是什么做前台行政，这中间当然就有父母来见面吃饭了，他们在开始恋爱不久就同居合租了，然后小娟父母就是来说要让她有个正经工作，对男的说的话就是人生就是责任这类的话，而小麦爸爸算是个导火索，因为小麦家里是做烟花生意的，他爸让他就做烟花生意，因为要回老家，并且小麦也不想做，所以就拒绝了，然后他爸就说不给他每个月五万的资助，这也导致了小麦需要去找工作，这个过程也是很辛苦，本来想要年前找好工作，然后事与愿违，后面有一次小娟被同事吐槽怎么从来不去团建，于是她就去了（我以为会拒绝），正在团建的时候小麦给她电话，说找到工作了，是一个创业物流公司这种，这里剧情就是我觉得比较俗套的，小麦各种被虐，累成狗，但是就像小娟爸爸说的话，人生就是责任，所以一直在坚持，但是这样也导致了跟小娟的交流也越来越少，他们原来最爱的漫画，爱玩的游戏，也只剩小娟一个人看，一个人玩，而正是这个时候，小娟说她辞掉了工作，去做一个不是太靠谱的漫画改造的密室逃脱，然后这里其实有一点后面争议很大的，就是这个工作其实是前面小麦介绍给小娟的那些朋友中一个的女朋友介绍的，而在有个剧情就是小娟有一次在这个密室逃脱的老板怀里醒过来，是在 KTV 那样的场景里，这就有很多人觉得小娟是不是出轨了，我觉得其实不那么重要，因为这个离职的事情已经让一切矛盾都摆在眼前，小麦其实是接受这种需要承担责任的生活，也想着要跟小娟结婚，但是小娟似乎还是想要过着那样理想的生活，做自己想做的事情，看自己爱看的漫画，也要小麦能像以前那样一直那么默契的有着相同的爱好，这里的触发点其实还有个是那个小麦的朋友（也就是他女朋友介绍小娟那个不靠谱工作的）的葬礼上，小麦在参加完葬礼后有挺多想倾诉的，而小娟只是想睡了，这个让小麦第二天起来都不想理小娟，只是这里我不太理解，难道这点闹情绪都不能接受吗，所谓的合拍也只是毫无限制的情况下的合拍吧，真正的生活怎么可能如此理想呢，即使没有物质生活的压力，也会有其他的各种压力和限制，在这之后其实小麦想说的是小娟是不是没有想跟自己继续在一起的想法了，而小娟觉得都不说话了，还怎么结婚呢，后面其实导演搞了个小 trick，突然放了异常婚礼，但是不是男女主的，我并不觉得这个桥段很好，在婚礼里男女主都觉得自己想要跟对方说分手了，但是当他们去了最开始一直去的餐馆的时候，一个算是一个现实映照的就是他们一直坐的位子被占了，可能也是导演想通过这个来说明他们已经回不去了，在餐馆交谈的时候，小麦其实是说他们结婚吧，并没有想前面婚礼上预设地要分手，但是小娟放弃了，不想结婚，因为不想过那样的生活了，而小麦觉得可能生活就是那样，不可能一直保持刚恋爱时候的那种感觉，生活就是责任，人生就意味着责任。

-

我的一些观点也在前面说了，恋爱到婚姻，即使物质没问题，经济没问题，也会有各种各样的问题，需要一起去解决，因为结婚就意味着需要相互扶持，而不是各取所需，可能我的要求比较高，后面男女主在分手后还一起住了一段时间，我原来还在想会不会通过这个方式让他们继续去磨合同步，只是我失望了，最后给个打分可能是 5 到 6 分吧，勉强及格，好的影视剧应该源于生活高于生活，这一部可能还比不上生活。

-]]> - - 生活 - - - 生活 - 看剧 - - 聊聊最近平淡的生活之看《神探狄仁杰》 /2021/12/19/%E8%81%8A%E8%81%8A%E6%9C%80%E8%BF%91%E5%B9%B3%E6%B7%A1%E7%9A%84%E7%94%9F%E6%B4%BB%E4%B9%8B%E7%9C%8B%E3%80%8A%E7%A5%9E%E6%8E%A2%E7%8B%84%E4%BB%81%E6%9D%B0%E3%80%8B/ @@ -14721,19 +14557,211 @@ $ - 聊聊这次换车牌及其他 - /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，估计在交管局那边我就懵逼了，各种插队，而且车子开着车子，也不能随便跑，所以建议办这个的时候有个人一起比较好。

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

+

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

+

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

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

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

+

+

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

+
<bean id="master1" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
+          destroy-method="close"
+          p:driverClassName="com.mysql.cj.jdbc.Driver"
+          p:url="${master1.demo.datasource.url}"
+          p:username="${master1.demo.datasource.username}"
+          p:password="${master1.demo.datasource.password}"
+          p:initialSize="5"
+          p:minIdle="1"
+          p:maxActive="10"
+          p:maxWait="60000"
+          p:timeBetweenEvictionRunsMillis="60000"
+          p:minEvictableIdleTimeMillis="300000"
+          p:validationQuery="SELECT 'x'"
+          p:testWhileIdle="true"
+          p:testOnBorrow="false"
+          p:testOnReturn="false"
+          p:poolPreparedStatements="false"
+          p:maxPoolPreparedStatementPerConnectionSize="20"
+          p:connectionProperties="config.decrypt=true"
+          p:filters="stat,config"/>
+
+    <bean id="master2" class="com.alibaba.druid.pool.DruidDataSource" init-method="init"
+          destroy-method="close"
+          p:driverClassName="com.mysql.cj.jdbc.Driver"
+          p:url="${master2.demo.datasource.url}"
+          p:username="${master2.demo.datasource.username}"
+          p:password="${master2.demo.datasource.password}"
+          p:initialSize="5"
+          p:minIdle="1"
+          p:maxActive="10"
+          p:maxWait="60000"
+          p:timeBetweenEvictionRunsMillis="60000"
+          p:minEvictableIdleTimeMillis="300000"
+          p:validationQuery="SELECT 'x'"
+          p:testWhileIdle="true"
+          p:testOnBorrow="false"
+          p:testOnReturn="false"
+          p:poolPreparedStatements="false"
+          p:maxPoolPreparedStatementPerConnectionSize="20"
+          p:connectionProperties="config.decrypt=true"
+          p:filters="stat,config"/>
+
+    <bean id="dataSource" class="com.nicksxs.springdemo.config.DynamicDataSource">
+        <property name="targetDataSources">
+            <map key-type="java.lang.String">
+                <!-- master -->
+                <entry key="master1" value-ref="master1"/>
+                <!-- slave -->
+                <entry key="master2" value-ref="master2"/>
+            </map>
+        </property>
+        <property name="defaultTargetDataSource" ref="master1"/>
+    </bean>
+ +

现在就要回到头上，介绍下这个DatabaseContextHolder，这里使用了 ThreadLocal 存放这个 DatabaseType，为啥要用这个是因为前面说的我们想要让接口层面去配置不同的数据源，要把持相互隔离不受影响，就使用了 ThreadLocal，关于它也可以看我前面写的一篇文章聊聊传说中的 ThreadLocal，而 DatabaseType 就是个简单的枚举

+
public class DatabaseContextHolder {
+    public static final ThreadLocal<DatabaseType> databaseTypeThreadLocal = new ThreadLocal<>();
+
+    public static DatabaseType getDatabaseType() {
+        return databaseTypeThreadLocal.get();
+    }
+
+    public static void putDatabaseType(DatabaseType databaseType) {
+        databaseTypeThreadLocal.set(databaseType);
+    }
+
+    public static void clearDatabaseType() {
+        databaseTypeThreadLocal.remove();
+    }
+}
+public enum DatabaseType {
+    MASTER1("master1", "1"),
+    MASTER2("master2", "2");
+
+    private final String name;
+    private final String value;
+
+    DatabaseType(String name, String value) {
+        this.name = name;
+        this.value = value;
+    }
+
+    public String getName() {
+        return name;
+    }
+
+    public String getValue() {
+        return value;
+    }
+
+    public static DatabaseType getDatabaseType(String name) {
+        if (MASTER2.name.equals(name)) {
+            return MASTER2;
+        }
+        return MASTER1;
+    }
+}
+ +

这边可以看到就是通过动态地通过putDatabaseType设置lookupKey来进行数据源切换，要通过接口注解配置来进行设置的话，我们就需要一个注解

+
@Retention(RetentionPolicy.RUNTIME)
+@Target(ElementType.METHOD)
+public @interface DataSource {
+    String value();
+}
+ +

这个注解可以配置在我的接口方法上，比如这样

+
public interface StudentService {
+
+    @DataSource("master1")
+    public Student queryOne();
+
+    @DataSource("master2")
+    public Student queryAnother();
+
+}
+ +

通过切面来进行数据源的设置

+
@Aspect
+@Component
+@Order(-1)
+public class DataSourceAspect {
+
+    @Pointcut("execution(* com.nicksxs.springdemo.service..*.*(..))")
+    public void pointCut() {
+
+    }
+
+
+    @Before("pointCut()")
+    public void before(JoinPoint point)
+    {
+        Object target = point.getTarget();
+        System.out.println(target.toString());
+        String method = point.getSignature().getName();
+        System.out.println(method);
+        Class<?>[] classz = target.getClass().getInterfaces();
+        Class<?>[] parameterTypes = ((MethodSignature) point.getSignature())
+                .getMethod().getParameterTypes();
+        try {
+            Method m = classz[0].getMethod(method, parameterTypes);
+            System.out.println("method"+ m.getName());
+            if (m.isAnnotationPresent(DataSource.class)) {
+                DataSource data = m.getAnnotation(DataSource.class);
+                System.out.println("dataSource："+data.value());
+                DatabaseContextHolder.putDatabaseType(DatabaseType.getDatabaseType(data.value()));
+            }
+
+        } catch (Exception e) {
+            e.printStackTrace();
+        }
+    }
+
+    @After("pointCut()")
+    public void after() {
+				DatabaseContextHolder.clearDatabaseType();
+    }
+}
+ +

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

+

这是我 master1 的数据，

+

+

master2 的数据

+

+

然后跑一下简单的 demo，

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

看一下运行结果

+

+

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

]]> - 生活 + Java + SpringBoot - 生活 - 换车牌 + Java + Spring + SpringBoot + Druid + 数据源动态切换 @@ -14955,6 +14983,22 @@ server.6=192.168< 生活 + + 聊聊这次换车牌及其他 + /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，估计在交管局那边我就懵逼了，各种插队，而且车子开着车子，也不能随便跑，所以建议办这个的时候有个人一起比较好。

+]]> + + 生活 + + + 生活 + 换车牌 + + 闲话篇-路遇神逻辑骑车带娃爹 /2022/05/08/%E9%97%B2%E8%AF%9D%E7%AF%87-%E8%B7%AF%E9%81%87%E7%A5%9E%E9%80%BB%E8%BE%91%E9%AA%91%E8%BD%A6%E5%B8%A6%E5%A8%83%E7%88%B9/ @@ -14971,103 +15015,59 @@ server.6=192.168< - 难得的大扫除 - /2022/04/10/%E9%9A%BE%E5%BE%97%E7%9A%84%E5%A4%A7%E6%89%AB%E9%99%A4/ - 因为房东要来续签合同，记得之前她说要来看看，后来一直都没来成，一方面我们没打扫过也不想被看到，小房子东西从搬进来以后越来越多，虽然不是脏乱差，但也觉得有点不满意干净状态，这里不得不感叹房东家的有钱程度，买了房子自己都没进房子看过，买来只是为了个学籍，去年前房东把房子卖给新房东后，我们还是比较担心会要换房子了，这里其实是个我们在乎的优点略大于缺点的小房子，面积比较小，但是交通便利以及上下班通勤，周边配套也还不错，有个比较大的菜市场，虽然不常去，因为不太会挑不会还价，还是主要去附近一公里左右的超市，可以安静地挑菜，但是说实在的菜场的菜还是比超市新鲜一些。
大扫除说实在的住在这边以后就没有一次真正意义上的大扫除，因为平时也有在正常打扫，只有偶尔的厨房煤气灶和厕所专门清理下，平时扫地拖地都有做，但是因为说实在的这房子也比较老了，地板什么的都有明显的老化，表面上的油漆都已经被磨损掉了，一些污渍很难拖干净，而且包括厨房和厕所的瓷砖都是纹路特别多，加上磨损，基本是污渍很多，特别是厨房的，又有油渍，我们搬进来的时候厨房的地就已经不太干净了，还有一点就是虽然不是在乡下的房子，但是旁边有两条主干道，一般只要开着窗没几天就灰尘积起来了，公司的电脑在家两天不到就一层灰，而且有些灰在地上时间久一点就会变成那种棉絮状的，看起来就会觉得更脏，并且地板我们平时就是扫一下，然后拖一下没明显的脏东西跟大灰尘就好了，有一些脏的就很难拖干净。
这次的算是整体的大扫除，把柜子，桌子，茶几台，窗边的灰尘都要擦掉，有一些角落还是有蛮多灰尘，当然特别难受的就是电脑那些接口，线缆上的，都杂糅在一块，如果要全都解开了理顺了还是比较麻烦，并且得断电，所以还是尽力清理，但没有全弄开了（我承认我是在偷懒，这里得说下清理了键盘，键盘之前都是放着用，也没盖住，按键缝里就很容易积灰也很难清理，这次索性直接把键全拔了，但是里面的清理也还是挺麻烦，因为不是平板一块，而且还有小孔，有些缝隙也比较难擦进去，只能慢慢地用牙线棒裹着抹布还有棉签擦一下，然后把键帽用洗手液什么的都擦一下洗洗干净，最后晾干了装好感觉就是一把新键盘了，后面主要是拖地了，这次最神奇的就是这个拖地，本来我就跟 LD 吹牛说拖地我是专业的，从小拖到大，有些地板缝边上的污渍，我又是用力来回拖，再用脚踩着拖，还是能把一些原来以为拖不掉的污渍给拖干净了，但是后来的厨房就比较难，用洗洁精来回拖感觉一点都起不来，可能是污渍积了太久了，一开始都想要放弃了，就打算拖干就好了，后来突然看到旁边有个洗衣服的板刷，结果竟然能刷起来，这样就停不下来了，说累是真的非常累，感觉刷一块瓷砖就要休息一会，但是整体刷完之后就是焕然一新的赶脚，简直太有成就感了。

+ 聊聊 Sharding-Jdbc 的简单原理初篇 + /2021/12/26/%E8%81%8A%E8%81%8A-Sharding-Jdbc-%E7%9A%84%E7%AE%80%E5%8D%95%E5%8E%9F%E7%90%86%E5%88%9D%E7%AF%87/ + 在上一篇 sharding-jdbc 的介绍中其实碰到过一个问题，这里也引出了一个比较有意思的话题
就是我在执行 query 的时候犯过一个比较难发现的错误，

+
ResultSet resultSet = ps.executeQuery(sql);
+

实际上应该是

+
ResultSet resultSet = ps.executeQuery();
+

而这里的差别就是，是否传 sql 这个参数，首先我们要知道这个 ps 是什么，它也是个接口java.sql.PreparedStatement,而真正的实现类是org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement,我们来看下继承关系

这里可以看到继承关系里有org.apache.shardingsphere.driver.jdbc.unsupported.AbstractUnsupportedOperationPreparedStatement
那么在我上面的写错的代码里

+
@Override
+public final ResultSet executeQuery(final String sql) throws SQLException {
+    throw new SQLFeatureNotSupportedException("executeQuery with SQL for PreparedStatement");
+}
+

这个报错一开始让我有点懵，后来点进去了发现是这么个异常，但是我其实一开始是用的更新语句，以为更新不支持，因为平时使用没有深究过，以为是不是需要使用 Mybatis 才可以执行更新，但是理论上也不应该，再往上看原来这些异常是由 sharding-jdbc 包装的，也就是在上面说的AbstractUnsupportedOperationPreparedStatement，这其实也是一种设计思想，本身 jdbc 提供了一系列接口，由各家去支持，包括 mysql，sql server，oracle 等，而正因为这个设计，所以 sharding-jdbc 也可以在此基础上进行设计，我们可以总体地看下 sharding-jdbc 的实现基础

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

在前一篇的 demo 中的

+
Connection conn = dataSource.getConnection();
+

其实就获得了org.apache.shardingsphere.driver.jdbc.core.connection.ShardingSphereConnection#ShardingSphereConnection
然后获得java.sql.PreparedStatement

+
PreparedStatement ps = conn.prepareStatement(sql)
+

就是获取了org.apache.shardingsphere.driver.jdbc.core.statement.ShardingSpherePreparedStatement
然后就是执行

+
ResultSet resultSet = ps.executeQuery();
+

然后获得结果
org.apache.shardingsphere.driver.jdbc.core.resultset.ShardingSphereResultSet

+

其实像 mybatis 也是基于这样去实现的

+]]> + + Java + + + Java + Sharding-Jdbc + + + + 聊聊最近平淡的生活之《花束般的恋爱》观后感 + /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 分吧，勉强及格，好的影视剧应该源于生活高于生活，这一部可能还比不上生活。

]]> 生活 生活 - 大扫除 + 看剧 - Leetcode 20 有效的括号 ( Valid Parentheses *Easy* ) 题解分析 - /2022/07/02/Leetcode-20-%E6%9C%89%E6%95%88%E7%9A%84%E6%8B%AC%E5%8F%B7-Valid-Parentheses-Easy-%E9%A2%98%E8%A7%A3%E5%88%86%E6%9E%90/ - 题目介绍

Given a string s containing just the characters '(', ')', '{', '}', '[' and ']', determine if the input string is valid.

-

An input string is valid if:

-
    -
  1. Open brackets must be closed by the same type of brackets.
    2. -
  2. Open brackets must be closed in the correct order.
    3. -
-

示例

Example 1:

-

Input: s = “()”
Output: true

-
-

Example 2:

-

Input: s = “()[]{}”
Output: true

-
-

Example 3:

-

Input: s = “(]”
Output: false

-
-

Constraints:

    -
  • 1 <= s.length <= 10^4
    • -
  • s consists of parentheses only '()[]{}'.
    • -
-

解析

easy题，并且看起来也是比较简单的，三种括号按对匹配，直接用栈来做，栈里面存的是括号的类型，如果是左括号，就放入栈中，如果是右括号，就把栈顶的元素弹出，如果弹出的元素不是左括号，就返回false，如果弹出的元素是左括号，就继续往下走，如果遍历完了，如果栈里面还有元素，就返回false，如果遍历完了，如果栈里面没有元素，就返回true

-

代码

class Solution {
-    public boolean isValid(String s) {
-
-        if (s.length() % 2 != 0) {
-            return false;
-        }
-        Stack<String> stk = new Stack<>();
-        for (int i = 0; i < s.length(); i++) {
-            if (s.charAt(i) == '{' || s.charAt(i) == '(' || s.charAt(i) == '[') {
-                stk.push(String.valueOf(s.charAt(i)));
-                continue;
-            }
-            if (s.charAt(i) == '}') {
-                if (stk.isEmpty()) {
-                    return false;
-                }
-                String cur = stk.peek();
-                if (cur.charAt(0) != '{') {
-                    return false;
-                } else {
-                    stk.pop();
-                }
-                continue;
-            }
-            if (s.charAt(i) == ']') {
-                if (stk.isEmpty()) {
-                    return false;
-                }
-                String cur = stk.peek();
-                if (cur.charAt(0) != '[') {
-                    return false;
-                } else {
-                    stk.pop();
-                }
-                continue;
-            }
-            if (s.charAt(i) == ')') {
-                if (stk.isEmpty()) {
-                    return false;
-                }
-                String cur = stk.peek();
-                if (cur.charAt(0) != '(') {
-                    return false;
-                } else {
-                    stk.pop();
-                }
-                continue;
-            }
-
-        }
-        return stk.size() == 0;
-    }
-}
- + 难得的大扫除 + /2022/04/10/%E9%9A%BE%E5%BE%97%E7%9A%84%E5%A4%A7%E6%89%AB%E9%99%A4/ + 因为房东要来续签合同，记得之前她说要来看看，后来一直都没来成，一方面我们没打扫过也不想被看到，小房子东西从搬进来以后越来越多，虽然不是脏乱差，但也觉得有点不满意干净状态，这里不得不感叹房东家的有钱程度，买了房子自己都没进房子看过，买来只是为了个学籍，去年前房东把房子卖给新房东后，我们还是比较担心会要换房子了，这里其实是个我们在乎的优点略大于缺点的小房子，面积比较小，但是交通便利以及上下班通勤，周边配套也还不错，有个比较大的菜市场，虽然不常去，因为不太会挑不会还价，还是主要去附近一公里左右的超市，可以安静地挑菜，但是说实在的菜场的菜还是比超市新鲜一些。
大扫除说实在的住在这边以后就没有一次真正意义上的大扫除，因为平时也有在正常打扫，只有偶尔的厨房煤气灶和厕所专门清理下，平时扫地拖地都有做，但是因为说实在的这房子也比较老了，地板什么的都有明显的老化，表面上的油漆都已经被磨损掉了，一些污渍很难拖干净，而且包括厨房和厕所的瓷砖都是纹路特别多，加上磨损，基本是污渍很多，特别是厨房的，又有油渍，我们搬进来的时候厨房的地就已经不太干净了，还有一点就是虽然不是在乡下的房子，但是旁边有两条主干道，一般只要开着窗没几天就灰尘积起来了，公司的电脑在家两天不到就一层灰，而且有些灰在地上时间久一点就会变成那种棉絮状的，看起来就会觉得更脏，并且地板我们平时就是扫一下，然后拖一下没明显的脏东西跟大灰尘就好了，有一些脏的就很难拖干净。
这次的算是整体的大扫除，把柜子，桌子，茶几台，窗边的灰尘都要擦掉，有一些角落还是有蛮多灰尘，当然特别难受的就是电脑那些接口，线缆上的，都杂糅在一块，如果要全都解开了理顺了还是比较麻烦，并且得断电，所以还是尽力清理，但没有全弄开了（我承认我是在偷懒，这里得说下清理了键盘，键盘之前都是放着用，也没盖住，按键缝里就很容易积灰也很难清理，这次索性直接把键全拔了，但是里面的清理也还是挺麻烦，因为不是平板一块，而且还有小孔，有些缝隙也比较难擦进去，只能慢慢地用牙线棒裹着抹布还有棉签擦一下，然后把键帽用洗手液什么的都擦一下洗洗干净，最后晾干了装好感觉就是一把新键盘了，后面主要是拖地了，这次最神奇的就是这个拖地，本来我就跟 LD 吹牛说拖地我是专业的，从小拖到大，有些地板缝边上的污渍，我又是用力来回拖，再用脚踩着拖，还是能把一些原来以为拖不掉的污渍给拖干净了，但是后来的厨房就比较难，用洗洁精来回拖感觉一点都起不来，可能是污渍积了太久了，一开始都想要放弃了，就打算拖干就好了，后来突然看到旁边有个洗衣服的板刷，结果竟然能刷起来，这样就停不下来了，说累是真的非常累，感觉刷一块瓷砖就要休息一会，但是整体刷完之后就是焕然一新的赶脚，简直太有成就感了。

]]> - Java - leetcode + 生活 - leetcode - java + 生活 + 大扫除 diff --git a/sitemap.xml b/sitemap.xml index 3e57f1ad4f..c98c2f3442 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -4,7 +4,7 @@ https://nicksxs.me/2022/08/21/%E4%B8%80%E4%B8%AA-nginx-%E7%9A%84%E7%AE%80%E5%8D%95%E8%AE%B0%E5%BF%86%E7%82%B9/ - 2022-08-21 + 2022-08-22 monthly 0.6 @@ -191,7 +191,7 @@ - https://nicksxs.me/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/ + https://nicksxs.me/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/ 2022-06-11 @@ -200,7 +200,7 @@ - https://nicksxs.me/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/ + https://nicksxs.me/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/ 2022-06-11 @@ -209,7 +209,7 @@ - https://nicksxs.me/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/ + https://nicksxs.me/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/ 2022-06-11 @@ -1424,7 +1424,7 @@ - https://nicksxs.me/2019/12/26/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D/ + https://nicksxs.me/2020/01/10/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%B8%89/ 2020-01-12 @@ -1433,7 +1433,7 @@ - https://nicksxs.me/2020/01/10/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D%E4%B8%89/ + https://nicksxs.me/2019/12/26/redis%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84%E4%BB%8B%E7%BB%8D/ 2020-01-12 @@ -1568,7 +1568,7 @@ - https://nicksxs.me/2016/10/12/summary-ranges-228/ + https://nicksxs.me/2016/07/13/swoole-websocket-test/ 2020-01-12 @@ -1577,7 +1577,7 @@ - https://nicksxs.me/2016/07/13/swoole-websocket-test/ + https://nicksxs.me/2016/10/12/summary-ranges-228/ 2020-01-12 @@ -1624,7 +1624,7 @@ https://nicksxs.me/ - 2022-08-21 + 2022-08-22 daily 1.0 @@ -1632,3019 +1632,3019 @@ https://nicksxs.me/tags/%E7%94%9F%E6%B4%BB/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/2020/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/2021/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%8B%96%E6%9B%B4/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Java/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/JVM/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/C/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/leetcode/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/java/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Binary-Tree/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/DFS/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%BA%8C%E5%8F%89%E6%A0%91/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%A2%98%E8%A7%A3/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Linked-List/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/2019/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/%E6%8A%80%E6%9C%AF/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/%E8%AF%BB%E4%B9%A6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/c/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B9%B6%E5%8F%91/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/j-u-c/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/aqs/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/condition/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/await/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/signal/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/lock/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/unlock/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/Apollo/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/value/ - 2022-08-21 + https://nicksxs.me/tags/%E8%AF%BB%E5%90%8E%E6%84%9F/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%B3%A8%E8%A7%A3/ - 2022-08-21 + https://nicksxs.me/tags/%E6%8A%80%E6%9C%AF/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/environment/ - 2022-08-21 + https://nicksxs.me/tags/%E8%AF%BB%E4%B9%A6/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/Stream/ - 2022-08-21 + https://nicksxs.me/tags/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/Comparator/ - 2022-08-21 + https://nicksxs.me/tags/Apollo/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%8E%92%E5%BA%8F/ - 2022-08-21 + https://nicksxs.me/tags/value/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/sort/ - 2022-08-21 + https://nicksxs.me/tags/%E6%B3%A8%E8%A7%A3/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/nullsfirst/ - 2022-08-21 + https://nicksxs.me/tags/environment/ + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Disruptor/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/Dubbo/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/RPC/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Filter/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Interceptor/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/AOP/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Spring/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Tomcat/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Servlet/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Web/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/G1/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/GC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Garbage-First-Collector/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%80%92%E5%BD%92/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Preorder-Traversal/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Inorder-Traversal/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%89%8D%E5%BA%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%AD%E5%BA%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Print-FooBar-Alternately/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/DP/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Shift-2D-Grid/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/stack/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/min-stack/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%9C%80%E5%B0%8F%E6%A0%88/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/tags/leetcode-155/ - 2022-08-21 + https://nicksxs.me/tags/DP/ + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/3Sum-Closest/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/linked-list/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Lowest-Common-Ancestor-of-a-Binary-Tree/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/First-Bad-Version/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/string/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Intersection-of-Two-Arrays/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Median-of-Two-Sorted-Arrays/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/dp/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%BB%A3%E7%A0%81%E9%A2%98%E8%A7%A3/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Trapping-Rain-Water/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%8E%A5%E9%9B%A8%E6%B0%B4/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Leetcode-42/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Rotate-Image/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%9F%A9%E9%98%B5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Remove-Duplicates-from-Sorted-List/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/linux/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/grep/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%BD%AC%E4%B9%89/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/mfc/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Maven/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/C/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Redis/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Distributed-Lock/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/hadoop/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/cluster/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/docker/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/mysql/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Docker/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/namespace/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/cgroup/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Dockerfile/ - 2022-08-21 + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/Dubbo/ + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/echo/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/uname/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8F%91%E8%A1%8C%E7%89%88/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Gogs/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Webhook/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8D%9A%E5%AE%A2%EF%BC%8C%E6%96%87%E7%AB%A0/ - 2022-08-21 + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/Stream/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/Comparator/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/%E6%8E%92%E5%BA%8F/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/sort/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/nullsfirst/ + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Mysql/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Mybatis/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Sql%E6%B3%A8%E5%85%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%BC%93%E5%AD%98/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/nginx/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%97%A5%E5%BF%97/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/openresty/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/php/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/mq/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/im/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/redis/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%BA%90%E7%A0%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%B7%98%E6%B1%B0%E7%AD%96%E7%95%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%BA%94%E7%94%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Evict/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%BF%87%E6%9C%9F%E7%AD%96%E7%95%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Rust/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%89%80%E6%9C%89%E6%9D%83/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%86%85%E5%AD%98%E5%88%86%E5%B8%83/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%96%B0%E8%AF%AD%E8%A8%80/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8F%AF%E5%8F%98%E5%BC%95%E7%94%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%8D%E5%8F%AF%E5%8F%98%E5%BC%95%E7%94%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%88%87%E7%89%87/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/spark/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/python/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Spring-Event/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/websocket/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/swoole/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/WordPress/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B0%8F%E6%8A%80%E5%B7%A7/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/gc/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%A0%87%E8%AE%B0%E6%95%B4%E7%90%86/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%9E%83%E5%9C%BE%E5%9B%9E%E6%94%B6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/jvm/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/MQ/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/RocketMQ/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%89%8A%E5%B3%B0%E5%A1%AB%E8%B0%B7/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%AD%E9%97%B4%E4%BB%B6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/ssh/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%AB%AF%E5%8F%A3%E8%BD%AC%E5%8F%91/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%90%90%E6%A7%BD/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%96%AB%E6%83%85/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%BE%8E%E5%9B%BD/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4%E8%BD%A6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8F%A3%E7%BD%A9/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%9D%80%E4%BA%BA%E8%AF%9B%E5%BF%83/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%89%93%E5%8D%A1/ - 2022-08-21 + https://nicksxs.me/tags/%E5%BC%80%E8%BD%A6/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%B9%B8%E7%A6%8F%E4%BA%86%E5%90%97/ - 2022-08-21 + https://nicksxs.me/tags/%E5%8A%A0%E5%A1%9E/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E8%B6%B3%E7%90%83/ - 2022-08-21 + https://nicksxs.me/tags/%E7%B3%9F%E5%BF%83%E4%BA%8B/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%BC%80%E8%BD%A6/ - 2022-08-21 + https://nicksxs.me/tags/%E8%A7%84%E5%88%99/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%8A%A0%E5%A1%9E/ - 2022-08-21 + https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E7%B3%9F%E5%BF%83%E4%BA%8B/ - 2022-08-21 + https://nicksxs.me/tags/%E8%B7%AF%E6%94%BF%E8%A7%84%E5%88%92/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E8%A7%84%E5%88%99/ - 2022-08-21 + https://nicksxs.me/tags/%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%85%AC%E4%BA%A4/ - 2022-08-21 + https://nicksxs.me/tags/%E6%9D%AD%E5%B7%9E/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E8%B7%AF%E6%94%BF%E8%A7%84%E5%88%92/ - 2022-08-21 + https://nicksxs.me/tags/%E5%81%A5%E5%BA%B7%E7%A0%81/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD/ - 2022-08-21 + https://nicksxs.me/tags/%E6%89%93%E5%8D%A1/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%9D%AD%E5%B7%9E/ - 2022-08-21 + https://nicksxs.me/tags/%E5%B9%B8%E7%A6%8F%E4%BA%86%E5%90%97/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%81%A5%E5%BA%B7%E7%A0%81/ - 2022-08-21 + https://nicksxs.me/tags/%E8%B6%B3%E7%90%83/ + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/git/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/scp/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%BF%90%E5%8A%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%87%8F%E8%82%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%B7%91%E6%AD%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B9%B2%E6%B4%BB/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%BD%B1%E8%AF%84/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%AF%84%E7%94%9F%E8%99%AB/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%9B%A4%E7%89%A9%E8%B5%84/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%AD%97%E7%AC%A6%E9%9B%86/ - 2022-08-21 + https://nicksxs.me/tags/RPC/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E7%BC%96%E7%A0%81/ - 2022-08-21 + https://nicksxs.me/tags/%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/utf8/ - 2022-08-21 + https://nicksxs.me/tags/stack/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/utf8mb4/ - 2022-08-21 + https://nicksxs.me/tags/min-stack/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/utf8mb4-0900-ai-ci/ - 2022-08-21 + https://nicksxs.me/tags/%E6%9C%80%E5%B0%8F%E6%A0%88/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/utf8mb4-unicode-ci/ - 2022-08-21 + https://nicksxs.me/tags/leetcode-155/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/utf8mb4-general-ci/ - 2022-08-21 + https://nicksxs.me/tags/DefaultMQPushConsumer/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/DefaultMQPushConsumer/ - 2022-08-21 + https://nicksxs.me/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%BA%90%E7%A0%81%E8%A7%A3%E6%9E%90/ - 2022-08-21 + https://nicksxs.me/tags/%E5%AD%97%E7%AC%A6%E9%9B%86/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/NameServer/ - 2022-08-21 + https://nicksxs.me/tags/%E7%BC%96%E7%A0%81/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/SpringBoot/ - 2022-08-21 + https://nicksxs.me/tags/utf8/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/cglib/ - 2022-08-21 + https://nicksxs.me/tags/utf8mb4/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E4%BA%8B%E5%8A%A1/ - 2022-08-21 + https://nicksxs.me/tags/utf8mb4-0900-ai-ci/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/Druid/ - 2022-08-21 + https://nicksxs.me/tags/utf8mb4-unicode-ci/ + 2022-08-22 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-08-21 + https://nicksxs.me/tags/utf8mb4-general-ci/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/NameServer/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/SpringBoot/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/cglib/ + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/tags/%E4%BA%8B%E5%8A%A1/ + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%87%AA%E5%8A%A8%E8%A3%85%E9%85%8D/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/AutoConfiguration/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%9C%E4%BA%AC%E5%A5%A5%E8%BF%90%E4%BC%9A/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%BE%E9%87%8D/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B0%84%E5%87%BB/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B9%92%E4%B9%93%E7%90%83/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%B7%B3%E6%B0%B4/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/SPI/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Adaptive/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%87%AA%E9%80%82%E5%BA%94%E6%8B%93%E5%B1%95/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Synchronized/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%81%8F%E5%90%91%E9%94%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%BD%BB%E9%87%8F%E7%BA%A7%E9%94%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%87%8D%E9%87%8F%E7%BA%A7%E9%94%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%87%AA%E6%97%8B/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%B1%BB%E5%8A%A0%E8%BD%BD/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8A%A0%E8%BD%BD/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%AA%8C%E8%AF%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%87%86%E5%A4%87/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%A7%A3%E6%9E%90/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%88%9D%E5%A7%8B%E5%8C%96/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%93%BE%E6%8E%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8F%8C%E4%BA%B2%E5%A7%94%E6%B4%BE/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/JPS/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/JStack/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/JMap/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/top/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Broker/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Sharding-Jdbc/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/ThreadPool/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%BA%BF%E7%A8%8B%E6%B1%A0/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/FixedThreadPool/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/LimitedThreadPool/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/EagerThreadPool/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/CachedThreadPool/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/mvcc/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/read-view/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/gap-lock/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/next-key-lock/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B9%BB%E8%AF%BB/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%B4%A2%E5%BC%95/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/is-null/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/is-not-null/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/procedure/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E7%A9%BF%E9%80%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E5%87%BB%E7%A9%BF/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%BC%93%E5%AD%98%E9%9B%AA%E5%B4%A9/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B8%83%E9%9A%86%E8%BF%87%E6%BB%A4%E5%99%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/bloom-filter/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%BA%92%E6%96%A5%E9%94%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%AE%BE%E8%AE%A1%E6%A8%A1%E5%BC%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Design-Patterns/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8D%95%E4%BE%8B/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Singleton/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Mac/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/PHP/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Homebrew/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/icu4c/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/zsh/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/ThreadLocal/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%BC%B1%E5%BC%95%E7%94%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%86%85%E5%AD%98%E6%B3%84%E6%BC%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/WeakReference/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%97%85%E6%B8%B8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%8E%A6%E9%97%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%AD%E5%B1%B1%E8%B7%AF/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%B1%80%E5%8F%A3%E8%A1%97/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%BC%93%E6%B5%AA%E5%B1%BF/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%9B%BE%E5%8E%9D%E5%9E%B5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%A4%8D%E7%89%A9%E5%9B%AD/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%A9%AC%E6%88%8F%E5%9B%A2/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%B2%99%E8%8C%B6%E9%9D%A2/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%B5%B7%E8%9B%8E%E7%85%8E/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E6%89%B6%E6%A2%AF/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%B8%A9%E8%B8%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%AE%89%E5%85%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%94%B5%E7%93%B6%E8%BD%A6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/Thread-dump/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%A4%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%B8%89%E9%98%B6%E6%AE%B5%E6%8F%90%E4%BA%A4/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/2PC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/3PC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%BF%9C%E7%A8%8B%E5%8A%9E%E5%85%AC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%AA%91%E8%BD%A6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%9C%8B%E5%89%A7/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%A3%85%E7%94%B5%E8%84%91/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E8%80%81%E7%94%B5%E8%84%91/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/360-%E5%85%A8%E5%AE%B6%E6%A1%B6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E4%BF%AE%E7%94%B5%E8%84%91%E7%9A%84/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E6%8D%A2%E8%BD%A6%E7%89%8C/ - 2022-08-21 + https://nicksxs.me/tags/Druid/ + 2022-08-22 + 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-08-22 weekly 0.2 https://nicksxs.me/tags/stream/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/zookeeper/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E7%9C%8B%E4%B9%A6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/tags/%E9%AB%98%E9%80%9F/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/tags/%E5%A4%A7%E6%89%AB%E9%99%A4/ - 2022-08-21 + https://nicksxs.me/tags/%E6%8D%A2%E8%BD%A6%E7%89%8C/ + 2022-08-22 weekly 0.2 - - - https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/ - 2022-08-21 + https://nicksxs.me/tags/%E5%A4%A7%E6%89%AB%E9%99%A4/ + 2022-08-22 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-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/ - 2022-08-21 + 2022-08-22 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-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/JVM/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/leetcode/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/leetcode/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/ - 2022-08-21 + https://nicksxs.me/categories/Java/GC/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/GC/ - 2022-08-21 + https://nicksxs.me/categories/Binary-Tree/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Binary-Tree/ - 2022-08-21 + https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/ + 2022-08-22 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-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/ - 2022-08-21 + https://nicksxs.me/categories/Linked-List/ + 2022-08-22 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-08-21 + https://nicksxs.me/categories/Java/leetcode/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Linked-List/ - 2022-08-21 + https://nicksxs.me/categories/C/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/%E5%B9%B6%E5%8F%91/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/java/ - 2022-08-21 + https://nicksxs.me/categories/%E5%B9%B4%E7%BB%88%E6%80%BB%E7%BB%93/2020/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/C/ - 2022-08-21 + https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Apollo/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/ - 2022-08-21 + https://nicksxs.me/categories/java/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/%E9%9B%86%E5%90%88/ - 2022-08-21 + https://nicksxs.me/categories/Java/Apollo/ + 2022-08-22 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-08-21 + https://nicksxs.me/categories/Filter/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Dubbo/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/Binary-Tree/ + 2022-08-22 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-08-21 + 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-08-22 weekly 0.2 - https://nicksxs.me/categories/Filter/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2021/ + 2022-08-22 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-08-21 + https://nicksxs.me/categories/DP/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/DP/ - 2022-08-21 + https://nicksxs.me/categories/linked-list/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/stack/ - 2022-08-21 + https://nicksxs.me/categories/Java/Apollo/value/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/leetcode/Lowest-Common-Ancestor-of-a-Binary-Tree/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/linked-list/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/Linked-List/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Apollo/value/ - 2022-08-21 + https://nicksxs.me/categories/%E5%AD%97%E7%AC%A6%E4%B8%B2-online/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/Binary-Tree/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%B9%B4%E4%B8%AD%E6%80%BB%E7%BB%93/2020/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E5%AD%97%E7%AC%A6%E4%B8%B2-online/ - 2022-08-21 + https://nicksxs.me/categories/Java/leetcode/Rotate-Image/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/leetcode/Rotate-Image/ - 2022-08-21 + https://nicksxs.me/categories/Linux/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Linux/ - 2022-08-21 + https://nicksxs.me/categories/Interceptor-AOP/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Maven/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/Binary-Tree/DFS/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Redis/ - 2022-08-21 + https://nicksxs.me/categories/Java/Maven/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Interceptor-AOP/ - 2022-08-21 + https://nicksxs.me/categories/Redis/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/data-analysis/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/docker/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Docker/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/Linked-List/ - 2022-08-21 + https://nicksxs.me/categories/Java/Dubbo/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/DP/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Mybatis/ - 2022-08-21 + https://nicksxs.me/categories/%E6%8C%81%E7%BB%AD%E9%9B%86%E6%88%90/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/DP/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/linked-list/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/nginx/ - 2022-08-21 + https://nicksxs.me/categories/Java/%E9%9B%86%E5%90%88/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/php/ - 2022-08-21 + https://nicksxs.me/categories/Java/Mybatis/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/stack/ - 2022-08-21 + https://nicksxs.me/categories/nginx/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/redis/ - 2022-08-21 + https://nicksxs.me/categories/php/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/linked-list/ - 2022-08-21 + https://nicksxs.me/categories/redis/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/Binary-Tree/DFS/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/string/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/ - 2022-08-21 + https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/leetcode/java/string/ - 2022-08-21 + https://nicksxs.me/categories/Spring/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Spring/ - 2022-08-21 + https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/ - 2022-08-21 + https://nicksxs.me/categories/Java/Spring/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/gc/ - 2022-08-21 - weekly - 0.2 - - - - https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E7%94%9F%E6%B4%BB/ - 2022-08-21 + https://nicksxs.me/categories/Redis/Distributed-Lock/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Redis/Distributed-Lock/ - 2022-08-21 + https://nicksxs.me/categories/Java/gc/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/ - 2022-08-21 + https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E7%94%9F%E6%B4%BB/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/MQ/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/ssh/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Spring/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%90%90%E6%A7%BD/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%85%AC%E4%BA%A4/ + 2022-08-22 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-08-21 + https://nicksxs.me/categories/Docker/%E4%BB%8B%E7%BB%8D/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%85%AC%E4%BA%A4/ - 2022-08-21 + https://nicksxs.me/categories/%E8%AF%BB%E5%90%8E%E6%84%9F/%E7%99%BD%E5%B2%A9%E6%9D%BE/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/git/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/shell/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Docker/%E4%BB%8B%E7%BB%8D/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E8%BF%90%E5%8A%A8/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mysql/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/Mybatis/Mysql/ - 2022-08-21 + https://nicksxs.me/categories/stack/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/SpringBoot/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mybatis/ - 2022-08-21 + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/categories/Java/Mybatis/Mysql/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/Dubbo/RPC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo-RPC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/%E7%B1%BB%E5%8A%A0%E8%BD%BD/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Thread-dump/ - 2022-08-21 + https://nicksxs.me/categories/Redis/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Dubbo-%E7%BA%BF%E7%A8%8B%E6%B1%A0/ - 2022-08-21 + https://nicksxs.me/categories/Thread-dump/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Redis/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/ - 2022-08-21 + https://nicksxs.me/categories/Dubbo-%E7%BA%BF%E7%A8%8B%E6%B1%A0/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Redis/%E5%BA%94%E7%94%A8/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/Design-Patterns/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mac/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/SpringBoot/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E6%97%85%E6%B8%B8/ - 2022-08-21 + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/grep/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E5%88%86%E5%B8%83%E5%BC%8F%E4%BA%8B%E5%8A%A1/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/Rust/ - 2022-08-21 + https://nicksxs.me/categories/Spring/Servlet/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Rust/ - 2022-08-21 + https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BC%80%E8%BD%A6/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/grep/ - 2022-08-21 + https://nicksxs.me/categories/%E8%AF%AD%E8%A8%80/Rust/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Java/gc/jvm/ - 2022-08-21 + https://nicksxs.me/categories/Rust/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/C/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/MQ/RocketMQ/ - 2022-08-21 + https://nicksxs.me/categories/Java/gc/jvm/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/ssh/%E6%8A%80%E5%B7%A7/ - 2022-08-21 + https://nicksxs.me/categories/MQ/RocketMQ/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Spring/Servlet/ - 2022-08-21 + https://nicksxs.me/categories/ssh/%E6%8A%80%E5%B7%A7/ + 2022-08-22 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-08-21 + 2022-08-22 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-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/git/%E5%B0%8F%E6%8A%80%E5%B7%A7/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/shell/%E5%B0%8F%E6%8A%80%E5%B7%A7/ - 2022-08-21 + 2022-08-22 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-08-21 + 2022-08-22 + weekly + 0.2 + + + + https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/echo/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BD%B1%E8%AF%84/2020/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/echo/ - 2022-08-21 + https://nicksxs.me/categories/leetcode/java/stack/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mysql/Sql%E6%B3%A8%E5%85%A5/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mybatis/%E7%BC%93%E5%AD%98/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/Dubbo/RPC/SPI/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo/ - 2022-08-21 + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/top/ - 2022-08-21 + https://nicksxs.me/categories/Redis/%E6%BA%90%E7%A0%81/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/ - 2022-08-21 + https://nicksxs.me/categories/Linux/%E5%91%BD%E4%BB%A4/top/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Mysql/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/ - 2022-08-21 + https://nicksxs.me/categories/%E9%97%AE%E9%A2%98%E6%8E%92%E6%9F%A5/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Redis/%E6%BA%90%E7%A0%81/ - 2022-08-21 + https://nicksxs.me/categories/Mysql/%E6%95%B0%E6%8D%AE%E7%BB%93%E6%9E%84/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mysql/%E7%B4%A2%E5%BC%95/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Redis/%E7%BC%93%E5%AD%98/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Java/Singleton/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mac/PHP/ - 2022-08-21 + 2022-08-22 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-08-21 + https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/ - 2022-08-21 + 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-08-22 weekly 0.2 - https://nicksxs.me/categories/C/Redis/ - 2022-08-21 + https://nicksxs.me/categories/Spring/Servlet/Interceptor/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/ - 2022-08-21 + https://nicksxs.me/categories/C/Redis/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Spring/Servlet/Interceptor/ - 2022-08-21 + https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/ + 2022-08-22 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-08-21 + 2022-08-22 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-08-21 + 2022-08-22 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-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Docker/%E5%8F%91%E8%A1%8C%E7%89%88%E6%9C%AC/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/MQ/RocketMQ/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Spring/Mybatis/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo/SPI/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo/%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E5%B7%A5%E5%85%B7/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mysql/%E6%BA%90%E7%A0%81/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/C/Mysql/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Mac/Homebrew/ - 2022-08-21 + 2022-08-22 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-08-21 + https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/grep/%E6%9F%A5%E6%97%A5%E5%BF%97/ + 2022-08-22 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-08-21 + 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-08-22 weekly 0.2 - https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/RocketMQ/ - 2022-08-21 + https://nicksxs.me/categories/Spring/Servlet/Interceptor/AOP/ + 2022-08-22 weekly 0.2 - https://nicksxs.me/categories/Spring/Servlet/Interceptor/AOP/ - 2022-08-21 + https://nicksxs.me/categories/%E6%B6%88%E6%81%AF%E9%98%9F%E5%88%97/RocketMQ/ + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E5%B0%8F%E6%8A%80%E5%B7%A7/top/%E6%8E%92%E5%BA%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo/%E7%BA%BF%E7%A8%8B%E6%B1%A0/ThreadPool/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E7%BC%93%E5%AD%98/%E7%A9%BF%E9%80%8F/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/PHP/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E4%B8%AD%E9%97%B4%E4%BB%B6/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/Dubbo/SPI/Adaptive/ - 2022-08-21 + 2022-08-22 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-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/PHP/icu4c/ - 2022-08-21 + 2022-08-22 weekly 0.2 https://nicksxs.me/categories/%E4%B8%AD%E9%97%B4%E4%BB%B6/RocketMQ/ - 2022-08-21 + 2022-08-22 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-08-21 - weekly - 0.2 - - - - https://nicksxs.me/categories/%E7%94%9F%E6%B4%BB/%E5%BC%80%E8%BD%A6/ - 2022-08-21 + 2022-08-22 weekly 0.2 diff --git a/tags/DP/index.html b/tags/DP/index.html index dc7c2bb5dc..44949a2918 100644 --- a/tags/DP/index.html +++ b/tags/DP/index.html @@ -1 +1 @@ -标签: dp | Nicksxs's Blog

Nicksxs's Blog

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

0%

dp 标签

2021
© 2022 Nicksxs
\ No newline at end of file +标签: dp | Nicksxs's Blog

Nicksxs's Blog

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

0%

dp 标签

2021
© 2022 Nicksxs
squs":"disqus"}} \ No newline at end of file diff --git a/tags/JVM/index.html b/tags/JVM/index.html index 2c42e09133..12487c0ff8 100644 --- a/tags/JVM/index.html +++ b/tags/JVM/index.html @@ -1 +1 @@ -标签: jvm | Nicksxs's Blog

Nicksxs's Blog

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

0%

jvm 标签

2021
© 2022 Nicksxs
\ No newline at end of file +标签: jvm | Nicksxs's Blog

Nicksxs's Blog

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

0%

jvm 标签

2021
© 2022 Nicksxs
rity":true,"url":"https://nicksxs.me/tags/JVM/"} \ No newline at end of file diff --git a/tags/linked-list/index.html b/tags/linked-list/index.html index c0f80771b5..6a350e72ab 100644 --- a/tags/linked-list/index.html +++ b/tags/linked-list/index.html @@ -1 +1 @@ -标签: linked list | Nicksxs's Blog

Nicksxs's Blog

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

0%

linked list 标签

2020
© 2022 Nicksxs
\ No newline at end of file +标签: linked list | Nicksxs's Blog

Nicksxs's Blog

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

0%

linked list 标签

2020
© 2022 Nicksxs
n-analytics.js"> \ No newline at end of file diff --git a/tags/mysql/index.html b/tags/mysql/index.html index 2260ce6dea..cb460e005c 100644 --- a/tags/mysql/index.html +++ b/tags/mysql/index.html @@ -1 +1 @@ -标签: Mysql | Nicksxs's Blog

Nicksxs's Blog

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

0%

Mysql 标签

2022
2020
© 2022 Nicksxs
\ No newline at end of file +标签: Mysql | Nicksxs's Blog

Nicksxs's Blog

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

0%

Mysql 标签

2022
2020
© 2022 Nicksxs
.js" integrity="sha256-vXZMYLEqsROAXkEw93GGIvaB2ab+QW6w3+1ahD9nXXA=" crossorigin="anonymous"> \ No newline at end of file diff --git a/tags/php/index.html b/tags/php/index.html index 99ed8d511d..1c981edf8a 100644 --- a/tags/php/index.html +++ b/tags/php/index.html @@ -1 +1 @@ -标签: PHP | Nicksxs's Blog

Nicksxs's Blog

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

0%

PHP 标签

2020
© 2022 Nicksxs
\ No newline at end of file +标签: PHP | Nicksxs's Blog

Nicksxs's Blog

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

0%

PHP 标签

2020
© 2022 Nicksxs
,"home":false,"archive":false,"delay":true,"timeout":3000,"priority":true,"url":"https://nicksxs.me/tags/php/"} \ No newline at end of file