时间飞快，还来不及多写几篇博客，2020已经结束。这时，总不免感叹时间都去哪儿了！

年初疫情导致全国各地的人都在家自我隔离，开启远程办公模式。没想到年末疫情有所反复，我仍然在家办公。在家办公对互联网行业/工作的人影响不大，甚至是利好。

对我个人而言，省去了上下班在路上的时间，能多睡会，在家穿着打理上更加随意，办公效率方面基本不受影响。工作方面，由于各种原因，9月份换了新的公司，工作内容的核心也发生了变化，不再直接参与消息中间件相关的研发。两年的基础研发对个人而言还是很受益的，非常感谢原团队的TL、同事的关照。对基础研发方面的爱好转变为参与相关社区的建设，期待未来在开源社区有更多的贡献。

你甚至可以在业余时间参与最大的开源项目之一的内部工作。

2018年10月，我开始为Kubernetes (K8s)做贡献，那时我在IBM的产品安全事件响应团队工作。我被分布式系统所吸引，但日常工作中接触不到，所以我的导师，孙林，建议我在空闲时间为开源的分布式系统做贡献。我开始对k8s感兴趣，再也没有回头。

在开发和运维系统过程中，难免会碰到CPU负载异常高的问题，第一印象是边界情况没处好，导致死循环。如何快速定位占用CPU的线程，甚至具体的代码块，对于解决线上问题非常关键。结合Linux自带的top命令和Java jstack可以轻松解决。

进程负载

Linux top 命令会展示系统当前的整体负载(load average)情况以及进程所占用的资源(PID、CPU、Memory等)，如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

top - 21:23:19 up 588 days,  3:17,  1 user,  load average: 3.28, 3.84, 4.55
Tasks: 417 total,   2 running, 415 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.4 us,  3.6 sy,  0.0 ni, 87.7 id,  0.0 wa,  0.0 hi,  0.3 si,  0.0 st
KiB Mem : 13141572+total,  4651624 free, 83008648 used, 43755452 buff/cache
KiB Swap:        0 total,        0 free,        0 used. 43701956 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
 9161 admin     20   0  0.105t 0.065t  15768 S 1709.2 53.4 109998:58 java
17551 root      20   0 3690796  32624   2548 S  18.8  0.0 309:22.70 lsecd
26748 root      20   0  146408   2156   1376 R   6.2  0.0   0:00.01 top
    1 root      20   0 1403740 1.162g   1852 S   0.0  0.9 185:42.10 systemd
    2 root      20   0       0      0      0 S   0.0  0.0   5:18.52 kthreadd
    3 root      20   0       0      0      0 S   0.0  0.0  99:12.84 ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 kworker/0:+
    8 root      rt   0       0      0      0 S   0.0  0.0  42:23.68 migration/0
    9 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcu_bh
   10 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/0
   11 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/1
   12 root      20   0       0      0      0 S   0.0  0.0   0:00.00 rcuob/2

Kafka在大数据、流式计算领域得到了广泛的应用，作为一个非常成熟的MQ产品，其中有许多值得学习借鉴的地方，本篇作为梳理Kafka设计和实现的提纲式文章，记录了梳理代码过程中的关键点及一些思考。

特性

Zookeeper 是一个容错的分布式协调服务通常用于维护配置信息、服务发现、Leader选举等场景。采用ZAB(Zookeeper atomic broadcast)共识算法使得服务集群高可用,例如一个5节点的服务集群最多可以允许2个节点不可用(宕机、网络隔离)，集群仍能对外提供服务。
ZAB协议主要有四个阶段(ZabState)：ELECTION > DISCOVERY > SYNCHRONIZATION > BROADCAST。Zookeeper实际使用三阶段:Fast Leader Election > Recovery > Broadcast,集群节点有四种状态(ServerState)：

当谈论分布式系统时，我们到底在谈论什么？通常来说，分布式系统是指分布在多个机器上的进程共同组成一个系统，对外提供服务，主要是为了解决Scalable问题，如分布式存储,分布式计算。为了能够使分布式系中的节点能达成一致状态，必须采用分布式算法，如PAXOS、RAFT和ZAB等。这些分布式算法的设计主要涉及几个理论，如FLP，CAP及BASE。

Java 7的变化

PermGen 区中移除了如下部分:

• 符号(Symbols)被移到本地内存

Java 对象的实例化JVM都做了那些事情？在日常编写Java项目的时候，实例化过无数多的对象，随时都在与JVM交互！对JVM的认识总是停留在只是知道它能解析识别，并加载运行Java编写的程序，好奇心驱使着我开始关注JVM是如何实现这一系列功能的。

即使读过《深入理解Java虚拟机》，对JVM的理解也只是达到一个入门的程度，开源的JVM实现凤毛菱角，为大家所熟知的OpenJDK自然成为了想一探究竟的入口，经过一番的搜寻，发现另外一本《Hotspot实战》让我看到了一丝希望。这本书买过来在我的书桌有一段时间了，最近终于有空仔细阅读了前面三章的内容，但纸上得来终觉浅，源码面前无秘密，跟着这本书终于满足我对JVM的一丝好奇心。

分布式事务中必须处理超时、节点(coordinator、participate)宕机、节点宕机恢复（fail-recover）、网络分区等异常情况。2PC和3PC基本概念