Arthas 线上排查 Java 问题实录Arthas 是阿里开源的 Java 诊断工具，核心能力是 attach 到运行中的 JVM 进程，不停机、不改代码，直接查线程状态、监听方法入参/返回值、分析调用链耗时。 安装与启动curl -O https://arthas.aliyun.com/arthas-boot.jarjava -jar arthas-boot.jar# 启动后会列出当前机器上的 Java 进程，输入编号选择要 attach 的进程 四个核心命令dashboard — 整体概览，快速定位问题线程 dashboard 进入 Arthas 后第一步通常先跑 dashboard，能看到所有线程状态、堆内存使用、GC 频率。CPU 飙高时，这里能直接看到哪个线程在占 CPU。 thread — 查看线程状态，找出 CPU 占用最高的线程 thread -n 3 # 显示 CPU 占用最高的 3 个线程的栈信息thread -b # 查找处于 BLOCKED 状态的线程（排查死锁）thread <线程ID> ...

低代码平台：技术人应该认真对待的事一、那时行业的声音2021 年是低代码话题的密集期。 钉钉发布宜搭，阿里云推出低代码引擎，各类平台的营销材料里都有一句类似的话：”让不懂编程的人也能搭建业务应用”。公众号上类似《低代码会替代程序员吗》的文章每隔一段时间就会出一篇，评论区里总有一批人在激烈争论。 有一次在公司的技术讨论群里，有人丢了一篇文章进来，说某大厂内部用低代码把一个部门的 CRUD 系统开发工期缩短了 80%。接下来大家的反应分成两类：一类人觉得这是在扯，一类人觉得这件事值得认真对待。 我当时属于第三类：不太确定，但觉得应该真的试一试再说。 二、我的第一反应说实话，最开始听到”低代码”这个词，我的第一反应是带着一点防御性的——这是给不懂技术的人用的，和我有什么关系？ 这种想法来得挺自然，也来得挺快。大概是某种职业性的本能：我学了好几年写代码，现在你说拖拖拽拽就能搞定，那我这些年算什么？ 但这个想法撑不住仔细想。我见过太多”绕过工程师”的工具最后还是得靠工程师才能用起来。我更好奇的是：低代码的边界在哪里？它真正擅长解决什么问题？ 于是我专门花了一周时间，把宜搭和某开源低代码平台（AM ...

猫咪版 Git 命令图解这套图来自国外创作者 Lynn Skursky 的”Git Purr”系列，用猫咪的行为类比 Git 核心命令，画风幽默但讲得挺准确。第一次看到时感觉比很多文字教程直观，收藏下来，顺手加了一些自己的理解注释。 图里的角色说明：猫咪对应本地仓库，云端/猫咪聚集地对应远程仓库，毛球/玩具对应 commit。 git purr（git pull） git pull = git fetch + git merge。从远端把最新的 commit 抓下来，直接合到当前分支。 日常用得最多，但多人协作时容易产生一堆多余的 merge commit，让提交历史看起来乱。如果想保持线性历史，可以改用 git pull --rebase。 git meowge（git merge & git rebase） merge：把两个分支的历史合并，保留所有提交记录，会产生一个 merge commit。历史真实，但图形复杂。 rebase：把当前分支的提交”搬”到目标分支的末端，历史是线性的，看起来干净。代价是改写了 commit 的 hash， ...

焦虑的旋涡已经焦虑好长一段时间了，陷入了一个很负能量的思维漩涡。 大事小事，各种事情都会产生焦虑，很不应该这样。 卖掉二手笔记本电脑，全程非常顺利，买家话少，事少，我却很担心中间会有什么其他纠纷问题，甚至担心有套路，很不应该这样啊。 今早坐地铁上班，旁边一个中年男子在用 Kindle 看纯英文的书籍，一个我曾经想冲动消费的电子设备，一个我一直以来最羡慕的语言技能，他拥有这些，却依然通着勤上班。我不喜欢。 我是不喜欢上班么？还是不喜欢把太多精力放在工作上？ 我想不清楚我到底向往什么样的生活，目光所及范围内，下一阶段的岗位并不感兴趣。 现阶段的焦虑，到底是因为压力，还是因为没有压力？

Docker Compose：用一个 yml 文件搞定本地开发环境以前本地跑项目，要先开 MySQL，再开 Redis，偶尔还有 RabbitMQ——每次开机都要挨个确认哪个没起来，换台电脑还得重新装一遍。有了 Docker Compose 之后，一条命令全搞定。 一个真实的 docker-compose.ymlMySQL + Redis + RabbitMQ 三件套，大多数 Java 后端项目够用： version: '3.8'services: mysql: image: mysql:8.0 container_name: dev-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: myapp ports: - "3306:3306" volumes: - mysql_data:/var/lib/mysql networks: - dev-net redis: image: ...

我第一次把项目跑在 Docker 里2020 年下半年，我开始认真研究 Docker。不是主动学的，是被逼的。 项目要迁到新服务器，运维说你们自己搞部署，给你们 Docker 环境。我当时 Docker 基本等于没用过，只知道是”跑容器的东西”。 那两周折腾下来，算是真正理解了容器化到底解决了什么问题。 一、之前的部署方式容器化之前，我们的部署流程大概是这样的： 本地打好 jar 包 用 FTP 或 scp 传到服务器 手动备份旧包，停掉旧进程 启动新包：nohup java -jar app.jar > app.log 2>&1 & 等个一两分钟，curl 一下接口看是否正常 每次上线都在走这几步。环境多了就是噩梦——开发环境、测试环境、生产环境，配置文件不一样，JDK 版本要核对，端口要确认，有时候某台机器上依赖的某个 so 库版本不对，就各种奇怪的问题。 “在我机器上能跑”这个问题我是真的遇到过，不是网上才有的梗。测试环境跑好好的，上了生产就报错，排查半天发现是两台服务器的 JDK 小版本不一样。 二、第一次接触 Docker 的契机就是上面说 ...

被讨厌的勇气刚听了一章《被讨厌的勇气》的解读，内容讲了两件事：目的论，和改变的勇气。 目的论的意思大概是——你以为自己是因为某件事”导致”了现在的状态，但阿德勒说不对，你其实是先有了”想维持现状”的目的，才反过去找了那个理由来撑腰。 听到这里有点不舒服，因为对号入座了。 大概从上周开始，我打算每天健身、练字，给自己定了个很简单的计划。前两三天还算顺利，到了第四天就开始松动了。晚上没去健身的时候，脑子里会自动冒出一个理由——身体有点不舒服，或者饭吃得晚了不适合运动。 说得挺有道理。但书里那句话一下把我钉住了：你不是因为身体不舒服才没去，而是你已经决定不去了，才找到了”身体不舒服”这个理由。 仔细想想确实是这样。那个理由从来不是我主动想出来的，它就那么自然地出现，像是我的大脑帮我提前准备好的一样。如果我真的想去，身体稍微有点不适大概不会是障碍。 这让我觉得，所谓的”执行力不够”，其实很多时候是个假问题。真正的问题是：你没那么想做这件事，但又不好意思直接承认，所以大脑帮你找了个体面的出口。 改变的勇气这部分我理解得更简单一些：改变会带来不确定性，现状哪怕不好，至少是熟悉的。所以很多时候”没时 ...

疫情居家的两个月，我重新审视了自己写的代码2020 年春节，原本只打算在家待一周，结果一待就是两个多月。 最开始几天还在刷新闻，后来慢慢定了下来，打开电脑，开始工作。居家远程那段时间，反而有了一些在公司里很久没有过的感受——第一次有空回头看自己写的代码了。 一、上班时的状态在公司里的日子，需求排着队来。今天这个功能要上线，明天那个 bug 要修，周报要写，评审要参加。 我们团队的 sprint 大概是两周一个迭代，每次排进来的卡基本都是满的。写代码的时候其实没怎么想”这样写对不对”，想的更多是”这样能跑起来吗””接口文档对上了吗””测试那边什么时候开始联调”。 代码 review 是有的，但很多时候都是走形式——互相看一眼，没有明显的 bug 就过了。确实没精力深究，也没人有时间纠结”这个方法是不是太长了”这种问题。 就这样日复一日，代码在赶节奏里写，很少有机会回头看它长什么样。 二、居家后的意外收获有一天，我在修一个线上小问题，改完了顺手往上翻，看了一眼那个模块周边的代码。这一看，就停不下来了。 那是一个做数据导入的模块，我大概一年前写的。我记得当时赶着上线，代码写得比较糙，心里 ...

我从未见过懒惰的人我从未见过懒惰的人； 我见过 有个人有时在下午睡觉， 在雨天不出门， 但他不是个懒惰的人。 请在我胡言乱语之前， 想一想，他是个懒惰的人，还是 他的行为被我们称为”懒惰”？ 我从未见过愚蠢的孩子； 我见过有个孩子有时做的事 我不理解 或不按我的吩咐做事情； 但他不是愚蠢的孩子。 请在你说他愚蠢之前， 想一想，他是个愚蠢的孩子，还是， 他懂的事情与你不一样？ 我使劲看了又看 但从未看到厨师； 我看到有个人把食物 调配在一起， 打起了火， 看着炒菜的炉子—— 我看到这些但没有看到厨师。 告诉我，当你看的时候， 你看到的是厨师，还是有个人 做的事情被我们称为烹饪？ 我们说有的人懒惰 另一些人说他们与世无争， 我们说有的人愚蠢 另一些人说他学习方法有区别。 因此，我得出结论， 如果不把事实 和意见混为一谈， 我们将不再困惑。 因为你可能无所谓，我也想说： 这只是我的意见。 ——鲁思·贝本梅尔