2022 第 13 周 - 技术分享记事

题图：翠华山-迎客松

标题周数已经跟今年实际周有所滞后，前段时间断更，现在补上。

要说 3 月中旬，不得不提一次内部投稿的体验。关于 JVM 垃圾回收调优的一次实践，由于是公司环境下的经验，很多内容需要脱敏，所以没有在外部平台进行投放。这篇稿子是年前疫情在家时定稿写完的，解封后没多久就过年了，所以迟迟没有审核推送。中间我催过一次，负责内部技术文章审核的团队回复：通过后会第一时间告知，于是就等到了 3 月份。

稿件内容是一些关于 JVM 参数配置调优的实践，典型问题有如下两种：

1. 年轻代、老年代大小设定不合理，年轻代过小，大量对象晋升老年代，oldGC 频繁，抢占 CPU 资源，导致 CPU 占用率居高不下，频繁报警。

2. 内存空间闲置，比如 8G 内存容器，JVM 堆内存仅设置 2G 大小，大量内存空间闲置，导致 GC 频繁，CPU 占用率居高不下。

关于内存利用率，在算法层面看则空间复杂度越低越好，但是系统层面则需要最大限度利用硬件资源，而不是让闲置空间占比过高。稿件结合了 JVM 原理以及内部工具使用的讲解，最终通过了审核。会在公司内部进行推广。

一切都挺顺利的，可就在推广时出现了一个小插曲，公司内部的文章推送分两批次，一个是公司内部技术社区，一个是公司内部的协同文档平台。收稿方在推送前联系过我，问我需要增加哪些 @人，当时在理解上存在偏差，我误认为我们同部门的同事都能收到（因为以往社区推送文章大家都能收到，后来得知两个平台推送方式不同），所以想着不需要再加 @人了，免得显得有些过于声张了。

推稿人则说道：那好，就把你的直属领导加上吧？

我说：好。

结果文章先是在社区推送，仅有我跟我的直属领导收到了，而且在文章开头有很醒目的人员 @列表，实践中一直协作的架构师没有署名自然也没收到，直到我跟他聊天时才得知。这下我觉得有些不妥了，毕竟这事非我一个人之功，现在搞得明显只有我一个人的署名，不免容易让人误会我在私吞劳动成果，幸好文章中有致谢章节，可是又有多少人真的仔细去从头看到尾呢？我立即找到推稿人问，有没有办法再加 @人，对方告知不行。无奈，我只能想其他途径：通过文章的评论区加了一段感谢我们架构师的话，这才让自己不安的情绪抚平了一些，最后这段话成了点赞最多的一条。晚间，第二批次推送，协同文档平台的推送是默认全员，自然大家都收到了。

在职场中，有那么一些小事情，却总是有着不小的影响：工作协作劳动成果公示时、发送邮件时的“收件人”，“抄送人”列表的排名、署名问题。看似很小的细节，往往能给自己招来不小的麻烦。记得有一次上线公告邮件，没有将我们小组内一位关键研发同事放在我的署名前边，后来引起了对方不满，虽然没有明说，但明显感觉到那几天他对我的态度有不少抵触情绪；还有一次是业务逻辑沟通环节的往来邮件，没有将一位业务同事放在收件人列表的靠前位置，对方直接私信问我你是不是觉得那谁谁是我领导？我有些莫名其妙，他才略带尴尬地说出那封邮件的收件人列表，我恍然明白，连忙解释，对方才一笑而过。索性后来我的往来邮件，如果存在收件人同事关系搞不清楚时，便加入一句“邮件收件人列表排名不分先后”这样的声明。

打工人多不易，一些人情世故还是需要自己琢磨的，别在小事情上招惹不必要的麻烦。