​ 上周两个应用CPU涨到500%，查看监控Major GC次数、耗时都暴涨：

​ 看情况很可能是内存泄漏了，接着看一下内存统计

jmap -histo

​ 发现一个不该存在如此多的对象竟然有200w+个：

1
2
3

 num     #instances         #bytes  class name
----------------------------------------------
  16:       2144453       51466872  com.xxx.XXXAction

​ 这个时候，进程不响应Jmx的请求了，埋点的监控诊断无法正常进行，并且这个时候已经是业务低峰期，干脆直接dump下内存，保留线程栈，然后重启应用。重启后业务恢复正常。

​ 内网发布用的配置数据库突然崩溃，查看mysql_error.log 可以看到只要一有写操作，一直在重复kill -6 -> recovery，无法自行恢复。摸索了两个小时，终于恢复完毕。现在记录一下主要的步骤。

​ 平时简单的写一些脚本或者看开源代码，打开IDEA太重了，一般都是VSC一把刷。由于不熟悉vsc的快捷键，效率实在太低，一开始用了IDEA Keybindings这个插件，但是总是有一些快捷键无法原生映射，用着反而嗝应，所以还是花点时间熟悉一下vsc上的快捷键，对照着IDEA的一些常用快捷键来对比熟悉。

​ 记录 Memory Anallyzer Tool 相关概念与使用。

​ 对性能和流量敏感，或者一些需要长连接的服务，都是自己再造一层应用层，而不是用http协议。自造应用层，绕不开的是用哪种编解码方式，而Protobuf就是其中一种高效的编解码协议。