最近在开发过程中，遇到了好多次 “这个需求点这次要不要做？” 的问题， 主要有两方阵营，比如以研发主导的 “这次先不做、等必要的时候再做” ，另外一方是以PM主导的 “这个不做需求不完整，可能影响用户体验” 。争议主要出现在一些小需求或者细节点上，一般不是啥核心功能，比如一些鸡肋需求或者有些极端异常case的处理。 前者的主要观点是“这个需求不重要可能会浪费时间，有哪些时间还不如做一些更重要的事”，后者的主要观点是“这个点虽然不是核心功能，但没有的话可能让用户决定我们产品有缺陷。” 如果遇到的两方脾气不好，甚至可能闹到剑拔弩张的情况。

  这两种不同的观点其实就是我标题上说的两种不同思维模式导致的，前者的思维模式更偏向于 “抓大放小，优先解决主要矛盾”，而后者的思维模式就是“细节决定成败，不放过一个问题”。不同的人在这两种思维模式上有不同的倾向，就是孰对孰错、孰优孰劣。这仿佛是个无解的哲学问题，下面我给出我对这个问题的答案，仅仅是一份我自己的观点，大家也可以在评论区探讨下。

  首先，我作为研发，大部分情况下的决策都是“不做”，因为做了会显著增加我的工作量，软件开发过程中也存在二八定律，80%的功能只占开发时间的20%，而剩余20%的功能需要额外投入80%工作量。剩下20%的功能ROI是极低的，这是我的第一个理由。 其次，很多需要点和细节点只是别人的假设，并不一定代表真实的场景，大部分情况下这个需求点是伪需求，直接拒绝可以有效避免研发人力的浪费。

  我们举个我所遇到的例子。我们公司的业务建立在某云之上，如果该云厂商宕机我们业务一定会挂，这显然从业务上讲这是不可容忍的，如果你去问老板，你希望自己的产品稳定性是多少，他一定会回答是100%。有一定技术经验的人都知道100%的稳定性是不可能达到的，我们只能无限趋近于100%。 摆脱单云依赖，我们唯一的选择就是要支持多云备份，然而这个成本巨高，可能需要我们全部技术吭哧吭哧改造几个月来完成，这对于一个以业务快速发展的团队来说也是不可接受的。在这件事上，我们都选择了坦然接受云厂商可能宕机的风险，选择抓大（业务发展）放小（极致的稳定性），

  再举一个决策完全相反的例子。我在入职阿里参加新员工培训的时候，听老员工将讲到了阿里曾经的去IOE项目，就是要在阿里巴巴的IT架构中，去掉IBM的小型机、Oracle数据库、EMC存储设备。其中我印象比较深的就是他讲到支付宝替换Oracle数据库过程中，他们投入了巨大的成本做数据稳定性一致性的验证，因为金融级别的数据就是要求100%的准确性，这种情况下就是追求极致的思维模式。

  可能有些同学也看出来以上两个案例决策结果不一致的原因。表面看是业务场景的不同，虽然我在案例一中没有具体介绍我们的场景，但大家也能看出来我们是可以接受不可用风险的，而且云厂商宕机其实算是小概率事件(虽然前两天阿里云就出事了)，短暂出问题后我们的损失远小于投入人力建设多云备份的能力的。而反观支付宝替换Oracle数据库的事，他们处理的是金融相关的数据，也就是和钱相关的数据，比如给你少算一分钱，这不仅仅是一分钱的问题，而是信任的问题，一旦出问题公司可能就黄了，所以他们出问题的成本是非常高的。 虽然这两个场景得出了不一样的决策，但其背后都遵循同一个原则，就是投入产出比最大化，大白话就是在同样的收益下成本最小或者在同样的成本下收益最大。

  投入产出比最大化 这个思路相信正常人都是认同的，那为什么同样一件事不同的角色在抓大放小和极致细节之间选择不同的思维方式？ 答案就是不同的人对收益和投入的评估结果是不一样的，有些时候做一件事投入的成本和预期收益是很难量化的，大家只能凭借自己的经验和感受做一个简单的评估，这个时候每个人评估的结果可能就会出现差异。我举一些观察到的现象（不一定完全准确）

• PM倾向于高估收益低估成本
• 研发倾向于低估收益
• QA倾向于高估风险
• 管理层和PM一样容易高估收益低估成本
• 不了解技术的人容易低估技术成本
• 乐观的人任意高估收益，悲观者容易高估风险
• 容易替别人低估成本，替自己高估成本
• 如果最近出过严重问题，容易高估风险
• ……

  有些是角色使然、有些是性格使然、还有些是环境使然，这些都很难控制，只能多沟通、建立规范、多尝试，各方在软件开发过程中，可以参考下这些建议，希望可以尽可能减少在成本和收益上的认知偏差。

1. 在评估收益时,我们应该考虑功能对用户和业务的实际价值，而不仅仅是满足用户的要求。很多用户需求可能只是“好奇心”或者“完美主义”,真正使用时作用不大。我们需要区分核心价值和边际价值。
2. 评估成本时，不要只看短期投入,还要考虑带来的长期维护成本。一个小功能可能需要持续Debug、完善、升级,总成本远超初期开发。
3. 沟通时,各方应摒弃主观偏见,不能因为立场不同就互不信任。研发应直面PM的质疑,而PM也应理解技术难点。管理层要站在全局角度平衡各方诉求。
4. 可以建立一套清晰的规范，说明不同类型需求的优先级原则、成本评估模型等,减少鸡肋需求的争议。并且可根据实际情况不断完善这套规范。
5. 在可行范围内，应该允许小规模试错,因为很多收益和成本在实际开发前难以准确预测。通过最小可行产品快速验证idea,再决定下一步优化方向。

  软件开发过程中的抓大放小和极致细节两种思维模式并没有明显的对错之分，至于不同的人选择不同的思维模式，源自于不同角色对收益和成本的认知偏差。但我认为在软件开发的不同阶段中，有着适合的不同思维模式，所以还是需要有倾向性的。 比如在软件开发初期或者资源有限的情况下，可以更倾向于抓大放小。但在软件稳定期更应倾向于极致细节。 当然如果遵循投入产出比最大的原则，一切都是可以自然而然改变的。比如在软件发展的过程中，有些功能初期不重要，但后期可能会变的很重要。所以还需保持开放和灵活的心态，根据不断变化的实际情况调整开发策略和优先级。

~谢谢打赏~

赏

  已经好几个月没有认认真真写一篇博客了，借着年底静下心来认认真真写一篇年终总结，这也是我人生中第10篇的年终总结了。 先看下去年立的flag，不用想去年立的flag一个都没完成。首先1 算是勉强及格；2 redis的博客一篇没写；3 一行代码没写；4 立flag时带的人因公司调整 run了（你懂得）；5 不要问我什么时候结婚，问就是明年。

  如果用一句话概括下过去的一年，那就是在忙碌的工作和普通的日常生活中逐渐陷入成长瓶颈中，当然我也知道在这样的大环境下，我的状态虽然不算太好，但也算还可以的了，希望大家在2023年能有更美好的工作和生活吧。接下来我分几大块，挨个说下我过去的一年吧！

关于工作

  在过去一两年大部分互联网公司都不在增长，甚至有很大一部分都在走下坡路的还是，我所处的团队却是快速增长，我们业务21年是从0-1，今年算是从1-10，虽然目前规模依旧不算大，但所有人都可以预期的是明年会有数倍的业务增长，这对我们团队的所有人而言是机遇也是挑战，当然我个人认为纯技术的挑战不多，更多是人和业务上的挑战。

  当然有好也有坏，在这样的环境下必然免不了忙碌，除了我自己 同组里的小伙伴也是经常加班，甚至周六日申请加班。忙碌有个最大的副作用，就是给我们很多应该干但没有干的事有了借口，就比如我 最近两个月都没怎么好好写过博客，不要问问就是太忙。再比如团队内，之前预定要做的好多事——文档整理、分享总结…… 几乎都没有了下文，原因都是因为太忙。

反思

关于工作我只有两点反思，这也是我在我们公司年终总结会上说的。

不要陷入过度忙碌的状态：

1. 长时间处于过度忙碌的状态会导致效率下降，影响工作和生活的质量。
2. 过度忙碌会遏制个人成长，让你没有时间接触新东西，没有时间总结和沉淀，没有时间去做未来的规划，最终陷入成长的死循环。 真正快速的成长过程应该是一张一弛、张弛有度的过程。
3. 忙碌可能成瘾，也可能会成为不去做很多事情的借口。

向外归因：

  我们之前接受到的教育基本都是从自身找问题，也就是向内归因，但我这么多年的经历其实看到，很多时候问题根本就不是自身的问题，举个我曾在阿里做运维时候的例子，16年作为阿里最后一批运维，我的工作内容真的是一言难尽…… 当时某位p9老板关注到我的工作状态，然后给了我用20%工作时间开发工具的建议，现在回想起来真是大有何不食肉糜的感觉，下面这个是我当时我组织架构往上好几层的老板毕玄今年写的一段话……

  总结起来很多事不是单靠自己就能解决的，可能你本身所处的环境就有问题，你得到的输入就是不够多，你能获取到的资源就是不够多，你就是没有得到足够的指导和支持，别人给的建议就是不适合你…… 这种情况下重点不只是把锅甩给别人，而是应该去关注外部的改变，而不是自身的不足，适时寻求外部力量的帮助。 我当年跳出成长困境最有效的方式就是换个团队、换个公司。

做好失业的准备

   这点我也不用展开讲了，毕竟现在是啥情况大家也都看到了，光我认识的人就好几个一直待业在家的。

关于个人成长

  我个人感觉今年几乎没有太多成长，书读的也不多，博客也没认认真真写，github上代码也早就不更了，连博客的阅读量和涨粉量也是靠着之前的老博文来的，工作中用到的技术也都是之前就会的。原因的话都能归结到工作太忙 压力太大，甚至有时候我都会想，如果在工作中得不到足够多的钱，我干这工作就是明显亏的。 我这状态幸亏没有毕业，要是毕业了岂不直接失业。

反思

自己才是成长的第一负责人

  在工作中成长确实是最快的方式，但让你能一直成长工作却是可遇不可求，不过这样的工作有一个明显的特点，那就是业务处于快速发展阶段，看目前的行情，你就知道这种工作有多难找了吧。所以大部分人还是比较难随着工作而长的，尤其是自身水平已经比较高的同学了，对于这部分人，不要指望工作能让你得到成长，大部分人真正的工作都是CURD，复杂点的就是有各种业务限制的CURD，技术上几乎不太可能让你成长。如果你处于真正状态，想要得到长必须靠自己，从本职工作中跳出来，多向外输出一些东西，比如文章、文档、工具、工作方法论…… 这样才是成长最快的方式。

不要听周围资深人士非技术相关的建议

   对于近两年毕业参加工作的同学，慎重听取周围资深人士的建议，尤其是在互联网行业。说句实话，很多人能到资深的位置，并不一定是因为个人能力优秀，而是因为他们赶上了互联网发展的浪潮，把他们推到那个位置了而已，而且他们的境遇和我们完全不同，所面临的问题和挑战也完全不同，很容易提出一些何不食肉糜之类的意见。
   说句实话，只要是别人不了解你的工作内容和工作情况，他们的技术建议也不要轻易听，他们很容易提出一些非常理想化的方案，可能在实际中完全无法落地，浪费掉你宝贵的时间。

关于业余生活

尝试发展一些“不良”嗜好

  今年我做了很多尝试，比如开始尝试玩游戏、追番、看网络小说…… 我确实比较容易入坑，但脱坑也很容易。年初玩了几个礼拜的使命召唤 目前已经小一年没玩了；年中玩俩月原神，也半年没玩了，年底追了好多个修仙的动漫，现在也弃坑了；最近刚刷完网络小说《吞噬星空》，也跳坑了； 这些东西对我有短期的吸引力，但长期没啥吸引力。
  不过今年能继续坚持下来的就是滑雪了，我人比较胆小 怕高怕伤，所以进步比较慢，不过多花点时间，还是能体会到滑行的乐趣。元旦定了去崇礼的计划，期望能有所进阶。
   这些“不良”嗜好对于工作和个人成长确实是负面的，但这些的的确确缓解了我的压力，并打发了我啥都不想干时候的时光。

你能在浪费时间中获得乐趣，就不是浪费时间。 ——罗素

关于明年

  可以预期明年团队的业务依旧会在高速发展期，所以依旧会比较忙碌，而且随着团队的人比较多、系统功能点也比较多，自己包括团队其他人应该会逐渐很难体会到价值感和存在感，过度的忙碌也会进一步减缓所有人成长的步伐，我希望自己明年能为对抗这些事做出一些贡献，首先给自己立个flag，每周不加班1-2天。
   再立几个非工作相关的flag，明年这个时候来看看倒不到。

1. 今年至少订婚，结婚可能推到明年。
2. 博客半月一更。
3. 22年搞过几个月的日常记录，因为工作忙碌中断了，今年希望365全勤。

最后祝大家2023年兔飞猛进 大展宏兔，依旧是附上我之前几年的总结。

• 21年年终总结
• 20年年终总结
• 19年年终总结
• 18年年终总结
• 17年年终总结
• 16年年终总结
• 15年年终总结
• 14年年终总结
• 13年年终总结

~谢谢打赏~

赏

导语

  同一份逻辑，不同人的实现的代码性能会出现数量级的差异； 同一份代码，你可能微调几个字符或者某行代码的顺序，就会有数倍的性能提升；同一份代码，也可能在不同处理器上运行也会有几倍的性能差异；十倍程序员 不是只存在于传说中，可能在我们的周围也比比皆是。十倍体现在程序员的方法面面，而代码性能却是其中最直观的一面。
  本文是《如何写出高性能代码》系列的第三篇，本文将告诉你如何写出GC更优的代码，以达到提升代码性能的目的

优化内存回收

  垃圾回收GC(Garbage Collection)是现在高级编程语言内存回收的主要手段，也是高级语言所必备的特性，比如大家所熟知的Java、python、go都是自带GC的，甚至是连C++ 也开始有了GC的影子。GC可以自动清理掉那些不用的垃圾对象，释放内存空间，这个特性对新手程序猿极其友好，反观没有GC机制的语言，比如C++，程序猿需要自己去管理和释放内存，很容易出现内存泄露的bug，这也是C++的上手难度远高于很多语言的原因之一。
  GC的出现降低了编程语言上手的难度，但是过度依赖于GC也会影响你程序的性能。这里就不得不提到一个臭名昭著的词——STW(stop the world) ，它的含义就是应用进程暂停所有的工作，把时间都让出来让给GC线程去清理垃圾。别小看这个STW，如果时间过长，会明显影响到用户体验。像我之前从事的广告业务，有研究表明广告系统响应时间越长，广告点击量越低，也就意味着挣到的钱越少。
  GC还有个关键的性能指标——吞吐率(Throughput)，它的定义是运行用户代码的时间占总CPU运行时间的比例。举个例子，假设吞吐率是60%，意味着有60%的CPU时间是运行用户代码的，而剩下的40%的CPU时间是被GC占用。从其定义来看，当然是吞吐率越高越好，那么如何提升应用的GC吞吐率呢？ 这里我总结了三条。

减少对象数量

  这个很好理解了，产生的垃圾对象越少，需要的GC次数也就越少。那如何能减少对象的数量？这就不得不回顾下我们在上一讲巧用数据特性 中提到的两个特性——可复用性和非必要性，忘记的同学可以再点开上面的链接回顾下。这里再大概讲下这两个特性是如何减少对象生成的。

可复用性

  可复用性在这里指的是，大多数的对象都是可以被复用的，这些可以被复用的对象就没必要每次都新建出来，浪费内存空间了。 处了巧用数据特性 中的例子，我这里再个Java中已经被用到的例子，这个还得从一段奇怪的代码说起。

Integer i1 = Integer.valueOf(111);
Integer i2 = Integer.valueOf(111);
System.out.println(i1 == i2);

Integer i3 = Integer.valueOf(222);
Integer i4 = Integer.valueOf(222);
System.out.println(i3 == i4);

  
  上面这段代码的输出结果会是啥呢？你以为是true+true，实际上是true+false。 What？？ Java中222不等于222，难道是有Bug? 其实这是新手在比较数值大小时常犯的一个错误，包装类型间的相等判断应该用equals而不是'==’，'==’只会判断这两个对象是否是同一个对象，而不是对象中包的具体值是否相等。
　
  像1、2、3、4……等一批数字，在任何场景下都是非常常用的，如果每次使用都新建个对象很是浪费，Java的开发者也考虑到了这点，所以在Jdk中提取缓存了一批整数的对象(-128到127)，这些数字每次都可以直接拿过来用，而不是新建一个对象出来。而在-128到127范围外的数字，每次都会是新对象，下面是Integer.valueOf()的源码及注释：

/**
     * Returns an {@code Integer} instance representing the specified
     * {@code int} value.  If a new {@code Integer} instance is not
     * required, this method should generally be used in preference to
     * the constructor {@link #Integer(int)}, as this method is likely
     * to yield significantly better space and time performance by
     * caching frequently requested values.
     *
     * This method will always cache values in the range -128 to 127,
     * inclusive, and may cache other values outside of this range.
     * 
     * @param  i an {@code int} value.
     * @return an {@code Integer} instance representing {@code i}.
     * @since  1.5
     */
    public static Integer valueOf(int i) {
        if (i >= IntegerCache.low && i <= IntegerCache.high)
            return IntegerCache.cache[i + (-IntegerCache.low)];
        return new Integer(i);
    }

  我在Idea中通过Debug看到了i1-i4几个对象，其实111的两个对象确实是同一个，而222的两个对象确实不同，这就解释了上面代码中的诡异现象。

非必要性

  非必要性的意思是有些对象可能没必要生成。这里我举个例子，可能类似下面这种代码，在业务系统中会很常见。

    private List<UserInfo> getUserInfos(List<String> ids) {
        List<UserInfo> res = new ArrayList<>(ids.size());
        if (ids == null || res.size() == 0) {
            return new Collections.emptyList();
        }
        List<UserInfo> validUsers = ids.stream()
                .filter(id -> isValid(id))
                .map(id -> getUserInfos(id))
                .filter(Objects::nonNull)
                .collect(Collectors.toList());
        res.addAll(validUsers);
        return res;
    }

  上面代码非常简单，就是通过一批用户Id去获取出来完整的用户信息，获取前要对入参做校验，之后还会对id做合法性校验。 上面代码的问题是 res对象初始化太早了，如果一个UserInfo没查到，res对象就白初始化了。另外，最后直接返回validUsers是不是就行了，没必要再装到res中，这里res就具备了非必要性。
  像上述这种情况，可能在很多业务系统里随处可见（但不一定这么直观），提前初始化一些之后没用的对象，除了浪费内存和CPU之外，也会给GC增加负担。

缩小对象体积

  缩小体积对象也很好理解，如果对象在单位时间内生成的对象数量固定，但体积减小后，同样大小的内存就能装载更多的对象，更晚才触发GC，GC的频次就会降低，频次低了自然对性能的影响就会变小。
  关于减少对象体积，这里我给大家推荐一个jar包——eclipse-collections，其中提供了好多原始类型的集合，比如IntMap、LongMap…… 使用原始类型(int,long,double……)而不是封装类型(Integer,Long,Double……)，在一些数值偏多的业务中很有优势，如下图是我对比了HashSet和eclipse-collections中IntSet在不同数据量下的内存占用对比，IntSet的内存占用只有HashSet的四分之一。

  另外，咱在写业务代码的时候，写一些DO、BO、DTO的时候没必要的字段就别加进去了。查数据库的时候，不用的字段也就别查出来了。我之前看到过很多业务代码，查数据库的时候把整行都查出来了，比如我要查一个用户的年龄，结果把他的姓名、地址、生日、电话号码…… 全查出来，这些信息放在Java里面需要一个个的对象去存储的，没有用到部分字段首先就是白取了，其实存它还浪费内存空间。

缩短对象存活时间

  为什么减少对象的存活时间就能提升GC的性能？总的垃圾对象并没有减少啊！ 是的 没错，单纯缩短对象的存活时间并不会减少垃圾对象的数量，而是会减少GC的次数。要理解这个就得先知道GC的触发机制，像Java中当堆空间使用率超过某个阈值后就会触发GC，如果能缩短对象的时间，那每次GC就能释放出来更多的空间，下次GC也就会来的更迟一些，总体上GC次数就会减少。
  这里我举个我自己经历的真实案例，我们之前系统有个接口，仅仅是调整了两行代码的顺序，这个接口的性能就提升了40%，这个整个服务的CPU使用率降低了10%+，而这两行顺序的改动，缩短了大部分对象的生命周期，所以导致了性能提升。

    private List<Object> filterTest() {
        List<Object> list = getSomeList();
        List<Object> res = list
                .stream()
                .filter(x -> filter1(x))  // filter1需要调用外部接口做过滤判断，性能低且过滤比例很少
                .filter(x -> filter2(x))  
                .filter(x -> filter3(x))  // filter3 本地数值校验，不依赖外部，效率高且过滤比例高
                .collect(Collectors.toList());
    }

  上面代码中，filter1性能很低但过滤比低，filter3恰恰相反，往往没被filter1过滤的会被filter3过滤，做了很多无用功。这里只需要将filter1和filter3互换下位置，除了减少无用功之外，List中的大部分对象生命周期也会缩短。
  其实有个比较好的编程习惯，也可以减少对象的存活时间。其实在本系列的第篇中我也大概提到过，那就是缩小变量的作用域。能用局部变量就用局部变量，能放if或者for里面就放里面，因为编程语言作用域实现就是用的栈，作用域越小就越快出栈，其中使用到的对象就越快被判断为死对象。

  除了上述三种优化GC的方式话，其实还有种骚操作，但是我本人不推荐使用，那就是——堆外内存

堆外内存

  在Java中，只有堆内内存才会受GC收集器管理，所以你要不被GC影响性能，最直接的方式就是使用堆外内存，Java中也提供了堆外内存使用的API。但是，堆外内存也是把双刃剑，你要用就得做好完善的管理措施，否则内存泄露导致OOM就GG了，所以不推荐直接使用。但是，凡事总有但是，有一些优秀开源代码，比如缓存框架ehcache就可以让你安全的享受到堆外内存的好处，具体使用方式可以查阅官网，这里不再赘述。

  好了，今天的分享就到这里了，看完你可能会发现今天的内容和上一讲 (二)巧用数据特性有一些重复的内容，没错，我理解性能优化底层都是同一套方法论，很多新方法只是以不同的视角在不同领域所衍生出来的。最后感谢下大家的支持，希望你看完文章有所收获。另外有兴趣的话也可以关注下本系列的前两篇文章。

如何写出高性能代码系列文章

• (一)善用算法和数据结构
• (二)巧用数据特性
• (三)优化内存回收(GC)

~谢谢打赏~

赏

大家好，我是XINDOO，今天是2022年的第一天，写下我过去一年的自我总结。这已经是我连续第9年写总结了，等明年的时候可能会来个十年大总结（对我过去8年有兴趣可以看下文末链接）。

21年 疫情、经济下行、大厂裁员…… 可能影响了很多人，但貌似对我没有太大的影响，过去的一年除了累点，总体上还是不错，各方面都算是向上走的，很多方面都渐入佳境，去年年终总结里里的flag也完成了一半多，接下来和我一起盘点下我过去的一年。

关于2021

读书

今年新读的书只有15本，也把之前几年读过的一些书又翻出来看了一遍，整体阅读量和去年差不多。相较于往年，今年增加了非小说类书籍的比例，确实比小说难度的多了，很多书需要不断定期翻阅才能逐渐消化吸收其中的内容。

学习

今年管住了自己的手，没买多少新课程，主要还是把之前买的课程回顾了下。今年看的比较多的课程不是技术类的，而是软技能相关，结合自己的工作经历将这些课程回顾了一遍，思考自己过去做的不足的地方。

博客

去年曾为自己的博客定下粉丝过万，阅读量过百万的目标，部分达成，粉丝到了1.5w，阅读量只有87w，还差13w成为百万博主。 过去的一年里总过写了26篇博客，还是保住了我之前立下了每月至少一篇的flag。但也有做的不好的，之前想着写个Redis源码相关专栏，写完10篇后就没有再继续写了，确实从21年4-5月份开始就一直忙，也就没有投入过多的精力在博客上了，所以你可能会发现我4-5月份之后的博客都比较水。

去年我雄心勃勃立下的开源计划，一个也没实现。 看我github的主页也知道，我去年就没提过几次代码，当然这一切原因都可以归咎到工作太忙(狗头)。不过令我比较意外的是我github去年依旧涨了200多个star，目前已经到了970+，star过千已经指日可待了，各位观众老爷们如果想帮我破千可以移步到我的github主页 帮我点几个star。

工作

21年4月是个转折点，4月前和4月后完全不是同一个状态，4月后我参与了3个比较大的项目，分别是不同的类型。一个技术性项目，做出来了，效果也很炫酷，但由于网络技术的问题，还没有在业务上落地；一个部门级的项目，虽然技术难度不大，但参与人众多，沟通和协调的挑战还是很大的，不过最后结果还可以，整体进度也是全公司第一；还有个创新性业务项目，目前已经成为了公司的明星项目之一。而4月前我还是做着到现在不温不火的项目(这部分内容已经交接给更专业的人去做了)，5月份试用期转正，我曾一度认为自己无法过试用期…… 我的故事告诉大家，如果想快速成长，找工作还是得找快速发展的业务。当然去年其他人的故事也告诉大家，如果你想躺平，那就滚出互联网[狗头]。

其他

生活方面，平静的生活没有被疫情打破，但疫情却让生活更平淡了，日常除了工作就是宅着。

另外就是滑雪学会了单板，虽然还是入门状态，但至少也能玩起来了。滑雪经历的心态变化也挺有意思的，从畏畏缩缩拒绝滑雪到战战兢兢站上雪板，然后逐渐突破，到最后的从容应对，像极了我做任何有挑战事情时的心态变化。

我做up主的事情也搁置了，20年抽空学了视频剪辑，21年毫无进展，预计22年依旧毫无进展。 不过我视频剪辑的技术21年也算是没有荒废，帮同学剪了婚礼vlog个， 还有就是给同事做了一批表情包，荣获表情包大师的称号(狗头)。

感悟&思考

去年做了很多工作，接触到了很多人和事，看过优秀的人也看过不优秀的人，有一些思考和感悟和大家分享下。

团队合作

当你开始与其他人合作的时候，你就会发现，工作中最难的事就是让别人做好一件事儿，相比之下反而任何技术难题都还好，毕竟自己手里的事，只要它是可解的，你付出努力一定能解决。但如果这件事涉及到了别人的帮助，那可能就费劲了，首先别人有没有能力解你不确定，即便别人有能力那他有没有空替你解? 他为什么要替你解？跨团队项目必须想清楚这些问题。

跨团队项目也有些套路，像是定期同步(站会、周会……)必不可少，风险管理也必不可少。大家也要有统一的目标，最好是都有共同的收益。 另外有些实在是推不动但又很重要的事，还是得动用下老板的力量……

想人所想

想人所想其实前面还有个急人所急，就是在别人有困难的时候给予援手，我这里就没有再写了，其实我重点是想强调下 想人所想，意思是要站在其他人的立场上去思考。大多数人的思维方式都是从自身角度去看待问题，这也是矛盾和争吵的根本原因之一。 当然我21年对这点深有体会不是因为矛盾和争吵，而是由于经常和人沟通出问题有些人总是站在自己专业的视角上和其他人沟通，却忽略了对方可能缺乏某些信息的事实。

举个很简单的例子，我们好多小伙伴都是纯业务开发出身，确实缺少很多架构、网络、系统相关知识，然后需要基础架构的同学协助排查时，经常出现只抛出表象，但不说上下文的情况，搞的基础架构的同学也无法入手。有时候基础架构的同学也会犯类似的错误，比如给回复个"你这个他简单，只需要在ingress上配个路由就行了"，可能他这一句话别人折腾一天都搞不定。再举个例子，我们内部很多工程师自己开发的系统太难用了，典型的技术人为技术人开发的系统，只有他们自己才知道怎么用，完全不是给其他人用的。

当你转变视角后，你就会发现很多事情都会顺畅很多，比如上面共同协助的问题，你只要把对方当小白，像对待小白一样给他提供详细和解决方案，你虽然会稍微多花点时间，但他的问题能很快得到解决，然后你就会收到好评。

全局思维

其实这条也是和团队合作相关，一个团队就好比是一套由齿轮传动的复杂机械装置，每个人都是其中某个齿轮，但由于每个人有不同的技术、背景、工作态度，导致每个人可能是规格 品质完全不同的“齿轮”，很多时候你只做好自己并不能保证你和其他人能高效协作起来，这时候需要你更进一步，关注到其他人的工作，从协作的角度帮助他人或自我做出调节。另外，从全局视角思考，也能帮助你做好自己那部分。

一个合格的程序猿能完成自己的工作。
一个优秀的程序猿能和别人一起完成工作。
一个优秀的管理者能让整个复杂的机械运转起来。

预期管理

管理好大家的预期很重要，这是我去年很重要的一个体会之一。当时是这样的，我们在推广一个新系统，告诉大家这个系统用起来非常好，迁移起来也很简单，结果一推广各种问题，导致有些人对这事有些不满。 就好比你小时候你考试承诺自己考100分但结果只有80分，和你承诺自己考60分但考了80分，虽然结果都是一样的，但带给人的感受却是完全不一样的。

所以没有太大把握的事不要太高调， 总结成一句话 不过度承诺，但承诺了一定要做到。

努力与运气

努力决定下限，运气决定上限。我工作了6年了，我刚毕业认识的一拨人里，有成为大厂中层的，也有身价几千万财富自由的，而我 比较一般，尤其是前两年 酸到不行。不是我不努力，而是有人一毕业榜上了高速增长的业务，而我阴差阳错做了运维，2年内完全被边缘化。这种类似的情况每个人都会有，不管你是谁，总会认识几个过的比你好的人。有些人只是凭运气乘上了一辆快车，然后达到普通人远不及的人生高度，这种在互联网领域里非常普遍，互联网缔造出了一堆亿万富翁，没有互联网他们什么都不是。

面对这种机遇导致的人生差异，我们普通人能做的只有摆正心态，不过分妒忌，然后凭借努力削弱运气的价值，抓住身边每个可能的机会。 说真的，有些东西你出生的时候没有，你这辈子大概率也不会有。

精力管理

我过去一年真的是我工作以来最忙的一年，有时候下班回家真的是感觉身体被掏空，没有精力干任何事，早上也起不来。虽然有些空闲时间，但是没有精力和体力，甚至晕车也晕出了新境界，从下班->打车->晕车的路径直接变成下班->晕车，然后博客、阅读、锻炼都停掉了。工作处于过饱和的状态，人生就会陷入停滞，不管怎样 每天还是要尽可能空出一些时间和精力，即便只是摸摸鱼也是有意义的。

每个人都拥有无限的创造力，只有在对自我时间的掌控中，人才能发挥天赋和创造力。

关于未来

照例，在总结的末尾依旧写下自己未来一年的目标。

1. 博客依旧会继续更新的，等明年掌握好工作的节奏，会投入更多的时间写一些更深度的内容。
2. 我的redis专栏，前两天有人催更了，有空还是要捡起来继续写完的，已经写了10篇了，估计再有10篇就能全写完了。
3. 作为一个古典程序猿，一种有各种造轮子的想法，前年就想着要写一门编程语言了，然而去年毫无进展，今年继续啊。
4. 工作还是继续稳步向上，除了本职工作外，要花更多的时间在带人上，希望自己的小伙伴也能快速成长起来，独挡一面。
5. 把结婚提上日程。

结语

工作6年，我确实变了很多，最明显的一点 从当初极度鄙夷业务推崇技术的我，变成了深入业务系统、离纯技术渐行渐远的我，不管别人归来时是不是少年，反正我已不是那个少年。

最后我没什么想说的了，上面都说完了，还是照例附上我之前几年的总结。

• 20年年终总结
• 19年年终总结
• 18年年终总结
• 17年年终总结
• 16年年终总结
• 15年年终总结
• 14年年终总结
• 13年年终总结

~谢谢打赏~

赏

对于大多数人来说，2020年啥也没干，就光见证历史了。前一段时间华盛顿邮报向读者征集如何描述2020年，一个九岁小孩拔得头筹。 过马路前你左右都看了，结果被潜水艇给撞了。 一句简单的调侃却道出了这一年的魔幻。

记得武汉封城那天晚上，我正好在回家的火车上，窗外车轮撞击铁轨声音吵得人无法入眠。当我打开微博看到武汉封城的通知，才意识到问题的严峻性，那一刻我隐约感觉到今年注定是不平凡的一年。

作为一个互联网宅男，我的2020受疫情影响很小，毕竟闭门不出是肥宅的日常。但我深知2020波澜不惊的我，要感谢很多人无畏的付出，其中不仅仅是那些医护工作者，还有那些为阻止疫情努力宅家的平凡人。 经历过疫情，再对比其他国家的现状，我也深刻体会到了群体中组织和协调能力的重要性。

回到我自己身上，我是一个平凡人，平凡人有自己平凡的一年，这一年有得有失、有好有坏，不过毫无意外的是年初的计划很多都没有完成，当然没完的原因很多，后面会详述。

总结起来，我觉得我过去的一年有几个比较大的部分。

1. 学习
2. 内容产出
3. 工作
4. 生活
5. 个人的成长

学习

17年看50多本书、18年40本、19年30多本、今年直接降到19本了，阅读量是直线下降，其实不是我不学习了，而是我是花了更多的时间在其他地方，不信你看下面。

19年和20年买过很多付费专栏，也花了大量的时间在这些专栏上面，收获颇丰也直接或间接给我带来了收益。其实很多人觉得付费专栏是收割智商税，也肯定以为我也被收割了，但实际我并不这么觉得。我买的很多技术专栏价格等同于一本书，算字数也不比一本书少，而且内容更新、更贴近实战，为啥买一本书不是收智商税而买专栏就是收智商税？

总结起来2020年输入还是颇丰的，真是学了不少，但明显感觉学的好多东西都在面上，从年底面试被虐的时候我就知道了。而且好多输入确实没有内化，更没有转变为输出，所以我准备在2021年重新回顾下之前的所看所学，转化为博客或者具体的项目。

内容产出

我觉得内容产出其实是我去年非常重要的一部分，不仅仅是因为我是个博主需要发博客，更重要的一点是内容的输出其实是我对输入信息的吸收，是我学习和成长最重要的一部分。强迫自己输出内容帮助我对所看所学有更深入的思考和理解，也会在外建立自己的技术影响力。不说别的，就我今年跳槽 其实我写了8年的博客对我帮助很大，我的博客可以让面试官从详细全面的视角去了解我（如果面试官愿意）。

博客

关于我的博客部分， 我还是比较满意的，今年原创+翻译大概更了近40篇，整体质量中上。虽然年初预想着博客访问量目标是破百万(年初是43w)，截止今天只有72w，不过年增长30w，已经是我这么多年涨的最多的一年了。 2020年我的粉丝量从1k多涨到了5k+，即便我最近没有更博客，日均还是有10+的持续增长，和大V们相比还是差很多，不过我还是挺知足的。

不过我一直知道自己的博客有个很严重的问题，就是想到啥写啥 不成体系，所以一直以来博客访问量偏低，所以20年甚至未来依旧会继续尝试写专栏文章，尝试把自己的博客内容体系化。

开源

2020年我github总共涨了400多star，出了一个正则引擎，完成了我大学时候的一个梦想。年初学了编译原理，后来突发奇想写一门编程语言，其实整体思路已经差不多 了，后来太懒没写完，算上前期准备大概完成6-70%左右吧。

2020年我开了Redis源码剖析专栏，阅读了一部分的redis的源码，出了几篇博客，虽然阅读量一般，读redis源码对我今年出去跳槽面试帮助很大，我对redis的了解程度已经超越大多数普通人了，虽然不敢说吊打面试官，但可以从容面对大部分的redis面试题了。另外，给redis水了两个commit，成为redis 400多位contributor中最水的一个。

2020年虽然在开源上有所得，但还是太水了，比如我成为redis的contributor之一，听起来高大上但实际就是改了两行注释。。。希望在2021年做出一些更有技术含量的贡献吧！ 不过这也意味着我要在上面投入更多的时间和精力。

公众号

年中我信誓旦旦想重拾公众号的，然后郑重其事发了一篇文章，结果后来就一直鸽，也不完全是因为懒的问题，要不然我今年还能更40篇博客？ 反思了下，其实很主要的一个问题是我没找准公众号的定位，我建号的时候我就决定不写技术相关，但至今没想出来除了技术我还能写啥，所以公众号一直处于长期断更的状态。

2021年希望我能找准定位，公众号逐渐更起来。我公众号二维码见左侧工具栏，有兴趣可以关注下。

视频

20年看到了好多技术博主在做视频内容，自己也想着出几个视频，然后也自学了点视频剪辑，入手了一些设备（麦、云台、三角架、nas），后来也在csdn、西瓜视频、视频号、B站传了几个视频，加起来有几万的播放量吧，但后来也没有精力去弄这些了。 这玩意真太耗时间和精力了，光录和剪视频得老半天了，比如我前两天我花4个小时剪了个3分钟的视频，这还不算前期的准备。当然可能我还是属于业余水平，专业up主会好很多。

可以预见的是2021我依旧没有太多的精力搞视频，索性就继续做一个佛系年更up主。

工作

11月25号我离开了工作了两年多的小米，第二天就入职了新公司。 离开的原因也很简单，不想再苟着了。我想寻找自己新的人生增长点，自私点就是想挣更多的钱，有个更好的发展。 当然我也有种想要为这个世界做一些微小贡献的想法 Make The World A Better Place。 也不是说小米不好，只是不符合我当下的目标而已。小米相对于其他公司，闲暇的时间会更多一些，让我有空去探索更多工作之外的东西，自由度也更高，但老是自己瞎搞，可能一不小心就跑偏了，而且也很难给自己带来实质性的收入，虽有成长，但也许跳出来成长会更快。

公司有选人的权力，人也有选公司的权力，公司觉得你不好的时候会开掉你，反之你也可以开掉公司。我这次跳槽的一个感悟，决定是否要跳槽以及跳哪需要从更长远的视角去看，因为很多人工作久了就会陷入一个舒适区，从当下的角度去看可能不动就舒服，但长远来看却不是。决定是否要跳槽可以简单看公司或者团队是否增长乏力，不增长的公司和团队迟早面临内卷！ ，另外也许你很难客观看待你公司和岗位长期的发展，建议你找个资深点的人问问，实在找不到就找猎头，多和猎头聊聊，他们接触的人很多，知道的信息会比你更多些。

今天我已经入职新公司一个月了，上次跳槽换方向（从sre转运维），这次直接换领域（从广告换其他业务领域）， 其实我也很想在同一个方向和领域深耕，可无奈时运不济。

生活

生活依旧那么平淡无奇，不过今年有个比较大的变化，对我感情生活一向不闻不问的我爸突然开始催婚了，毕竟前天我已经是27岁的人了，小学同学的孩子都上小学了，中学同学都已经二胎了，大学同学已经结婚了，读研究生\博士的人还单身，不由的感叹一句 知识改变命运啊。

20年的计划里有个重新练出腹肌，很明显没有实现，而且由于疫情的原因，跑步的计划也搁置了好久，最终的结果就是肚子上的肉越来越多了，好在我还是把体重控制住了，不求2021练出腹肌，但求没有小肚腩。

个人感悟

精力管理

2020年是我单程通勤超过1小时的第三年，一个很明显的体会就是每天早上的时候，还可以在地铁上看会书、学会习，但晚上回家的时候就完全学不进去了，就想着看下视频、刷会微博，然后我就经常因为自己沉溺于消磨时间而感到愧疚。 但我后来才发现忙碌了一天其实精力已经消耗差不多了，确实很难专注下来，那为什么不直接放飞自我，养精蓄锐来日再战。引用一句名言：

那个时候我年轻想办好事，差不多一个月大病一场。为什么呢？老熬夜。经常是通宵达旦干。后来最后感觉到不行，这么干也长不了。先把自己的心态摆顺了，内在有激情，外在还是要从容不迫。因为我当时是看书还是谁跟我讲了一句很智慧的话，说你手里攥着千头万绪，工作是千头万绪，攥着一千个线头，但是一次针眼只能穿过一条线。后来我就想了一个，今天(晚上)做到12点，就不做了睡大觉，第二天重新来过。

再后来我也切身体会到人一天的精力也是分时间段的，早上精力最为旺盛，中午到饭点了就不行了，然后下午5点左右的时候也不太行。精力不行的时候老想着划水，心中不免对公司有种愧疚感，之后逐渐发觉长期的低效投入还不如短期的全身心投入，然后就心安理得的划水了。不过划水的时候看一些乱七八糟的东西，也涨了不少见识，有机会出篇博客给大家讲讲我在公司划水的时候都在干些什么？。

BTW：精力差的时候可以划水摸鱼恢复精力，精力好的时候还是要努力打工的呀，这样你的老板们年底才能换房换车[狗头]。

学会复盘

复盘是我几年前在做运维的时候学到的一个词，当时每次出线上问题后，一帮人就会聚在会议室总结分析问题，讨论未来如何避免类似的问题发生，然后列一堆的Todo。 复盘会参与的多了，就发现每次复盘后的Todo就是那几项（哈哈）。。。

不过我今天要说的复盘指的是自我复盘，准确说是对自我过去一段时间的总结、分析和改进。定期的自我复盘是要自身的问题和不足，然后提出改进的措施，让自己以后能做的更好。当然做的好的地方也别忘记奖励下自己。

我还学到的一点就是，也许自己的经历不够丰富，但可以偷偷摸摸通过复盘别人来提升自己，从别人身上取其精华去其糟粕来获得自己的提升。

承认自己是普通人

其实说句实话，我骨子里一直都不觉得自己是一个平凡人。我时常在想为什么我就是我，为什么我可以思考也可以行动，为什么我可以通过我的思想和行为去改变我周围的东西？甚至有时候我都觉得整个宇宙只有我是真实的，你们其他人都是这个宇宙中陪我的NPC。典型的唯心主义。

但我后来经历的事告诉我，这个世界有很多事是我控制不了的，也有很多东西不是仅凭自己的努力就能拿到的，还认识的这个世界本质是不公平的，自己只是这个世界毫不起眼的一小部分。如果我是一束光，也只是萤火之光，也许连方寸之间都无法照亮，怎么敢和日月争辉。

明白了这点，面对自己的失败和缺点，我的心态也变的更平和，不再那么容易陷入深深的自责，不再那么容易怀疑人生怀疑自我。另外说一句，不光你自己，你周围其他人也都是普通人。

行胜于言

2020年不是想着录视频吗，老觉得题材没想好、缺素材，然后始终不见动手去做，然后就一直鸽，但有次周末一咬牙开始做，从写稿+录音+ppt，到最后的剪辑 一天多就搞定了，最后效果还可以。还有我每次写博客，其实写之前我都不知道要怎么写，但如果逼自己坐下来直接开写一会功夫洋洋洒洒一篇博客就出来了。就好比今天写这个总结，之前虽然列了个大纲，也不知道填哪些内容，但开始写之后就刹不住了，这不已经快5000字了，还有很多内容没写。。。。。

所以，不知道具体怎么做，就先动手干起来，有些东西光想永远也想不清楚，但可以做出来。 不过我有时候还是做不到，空闲时刻躺着它不香吗！！

2021年计划

年初必立flag，年末flag必倒，这点我已经验证过好几年了，2021年也不想立太多的flag，谨防被打脸。之前几年立的很多flag太不切实际，也错误的估计了自己能力，

所以我的2021没有太多新的内容，还是之前的东西。

• 快速融入新工作，有能力承担重要角色。
• Redis专栏继续更下去，保持每月至少2篇的节奏。
• 博客粉丝过万，pv总能破百万了吧！
• 视频内容的话能更就更，更不了就拉倒，做一个佛系up主。
• 之前看过的很多书重新看一遍。
• 把我的ulang 1.0版写出来。

写在最后

最后我没什么想说的了，上面都说完了，还是照例附上我之前几年的总结。
19年年终总结
18年年终总结
17年年终总结
16年年终总结
15年年终总结
14年年终总结
13年年终总结

~谢谢打赏~

赏

时光荏苒，岁月如梭，不知不觉一年又过去了。19年的互联网格外的不景气，到处充斥着暴雷、裁员，然而这些都和我无关，但这些都让深刻认识到了困难时期抱着大厂大腿的好处（还好我18年没跳槽去小厂，哈哈）。 回到年终总结，这已经是我连续第七年写年终总结了(文末可以看到其他年份的)，首先我们来回顾下去年立的flag。

没错，和大多数人一样，去年的flag都白立了。不过和大多数人不一样的是，我的19年不算是白过了，个人还是经历过一些事，取得过一些成就的。

几个重要事件

亲历996

19年的第一个工作日，我就接到了996的通知，这次996只持续了一个季度。后来十一的时候又996过一次，不过倒是没持续几周。虽然之前做过运维，7*24小时oncall，就是大家号称的007，如果运气不好确实是很辛苦，但996带给我的感觉和007的oncall却完全不一样，oncall是个人的悲惨，但996是团队的不幸。我亲眼目睹了我司很多团队的大换血，一个团的分崩离析你可以归结到业务，但人员频繁流动你只能归结到管理。

放弃了一些好习惯

1. 放弃了刷leetcode，过去的很长一段时间，我都一直在刷leetcode，截止今日已经刷了600题，之前一直保持一周3-5题的速度。 后来我仔细思考过，感觉刷题已经到了瓶颈，该会的都会了，不会的也很难会了，之前蛮力刷题的方式性价比已经很低了，倒不如先不刷了把时间拿去干其他事儿。
   
2. 放弃刷题的同时也放弃了扇贝英语打卡，算下来我连续打卡1300多天，将近4年的时间，放弃的原因和上面类似，自己目前对英语没有更大的需求了，用不到口语和写作，看英文文档的话单词量已经基本足够。
3. 放弃了漫无目的的读书。如果你关注我的豆瓣你就会发现我今年的阅读量只有30多本，应该是最低的一年。尽管之前几年的阅读量很高，但深度阅读很少，真正学到的东西还是比较少的，学习的性价比比较低，所以有意识的减少了阅读量，另外还有一点是极客时间的影响，等会会谈到。

看了极客时间10+的专栏

我算是极客时间的重度用户了，买了很多课(30+)吧，折算成人民币也得大2k了。有人说知识付费就是收智商税，知识付费刚出来的时候我也是这么认为的，尤其是看到一些哗众取宠的标题时。但我觉得我在极客时间没有交智商税，一门专栏基本上相当于一本书的价钱，单从字数来看也相当于一本书，但专栏的作者可能比那些烂书的作者更具实践经验、更贴近技术前沿、更懂的通俗易懂地讲清楚某事。所以你为什么不觉得买一本书就是收智商税呢？ 当然客观上来讲，有些专栏的性价比确实不高或者不适合你，学会信息筛选很重要。

做了牙齿矫正

工作这几年来，我的牙陆陆续续出了好几个小问题，最严重的问题就是开颌(上下牙无法咬合)，其实并不太影响生活，就每次吃饭咬东西咬不断很难受，想起来就很膈应人，一狠心一咬牙就去做了矫正，大概3w就出去了。你问我值不值，我钱都花出去了，我能说不值吗。
牙齿矫正是个很漫长的过程，我的牙齿矫正需要大概两年的时间，但是需要4-5年的时间矫正我错误的吞咽习惯，否则可能复发。试想如果当我在小时候就有人告诉我正确的吞咽方式就不会这样了。小时候的因现在的果，仔细想想这只是其中一个缩影，也许我在很多个方面用错误的方式在做事，这一切的根源是我出生在一个比较落后的地区。突然想到，穷人想过上和富人一样的生活，是不是得承担远高于富人的成本。

博客走入正轨

今年是第8年写博客了，19逐渐写了有些深度内容，有几篇反响还是挺不错的，也得到了好多网友的认可，csdn的原力计划也让我第一次因为写博客赚到到了稿费（实际不多，鼓励意义远大于金钱价值），2020继续努力。（在2020年的第10天，又一次收到了原力计划的稿费，这算是2020年的开门红吗？）

Github收获300+星

300星对大佬们来说不算什么，但对我来说是个非常好的开端。300多星来自我和几个朋友们翻译的项目eng-practices-cn，谷歌开源的一些工程实践的内容，感兴趣的朋友可以关注下。

个人成长

技术成长

今年因为看了好多极客时间的专栏，所以自我感觉在技术上也有一些成长，但因为学的很多内容都没运用到实践上，所以还是算是纸上谈兵。但也有些内容还是用到了工作中了，也算是小有成果，比如：

性能优化

虽然目前为止，职业生涯的一半都是在做运维，但实际更像是技术客服，所以很多linux命令、工具都在之前没有真正掌握过。自从后来转行做开发，遇到好多实际的问题， 才在实践中掌握了好多性能问题排查命令，实际上工作中也用arthas、mat、fastthread、wrk等工具真真切切定位了好多性能问题，提升了我们系统性能。年初我把我们一个系统的吞吐能力提升了5倍，后半年也把我们在线引擎极限性能提升了100%+，也为特殊活动准备了一些应急开关，可以把极限性能再提升100%+（有业务影响）。

问题排查

我是在一个偏业务的团队，查过好多业务问题，但一般没啥成就感，还是比较喜欢查技术问题。今年其实我们遇到了两个jdk的bug，都是在jdk13的版本才修复的。一个是javax.crypto.Cipher 频繁调用性能问题，另一个是jdk11 zgc 性能bug (jdk11的所有发行版目前都未修复)，这个问题还挺有意思的，之前一直想写篇博客，材料都准备差不多了，就是太懒了。
第一个问题我们选择忽略，因为复现频率很低，都是在访问启动的时候jit还没预热好然后有大量流量进来，偶尔复现，但我们调整启动策略后就没了。另一个问题困扰我们团队好久，几个月都没查出来，后来还是我给他们推荐了arthas才发现问题的，这个故事告诉我们好用的工具是有多关键。后来我细究了下这个bug的机理，这个后面我会出一篇博客专门介绍的，感兴趣可以提前关注下我的博客。

btw：最近我们又用arthas的火焰图揪出了一个性能问题，把我们一个服务的性能提升了10倍+，再次强烈安利下下arthas。

非技术成长

非技术类的软实力提升很难量化，到一定瓶颈之后也很难提升，我过去一年的关注点可能并不在这上面，所以…… ƪ(˘⌣˘)ʃ 。不过今年积累了好多乱七八糟的素材。。

工作&生活

工作还算比较顺利，就是单程1个多小时的通勤时间让人………… 和女朋友关系很稳定，几乎没闹过别扭、没吵过架，她父母那边要是不为难我的话基本就到谈婚论嫁的时间了。
日常生活…… 程序猿的日常生活就是那么朴实无华且枯燥，你懂得。。。

新年计划

最后一个项目，立下新的flag，最简单最敷衍的方式就是...

开个玩笑，不过19年的部分flag还是要捞出来再立一下的，比如腹肌、英语、开源。。。。

• 年底尽量考一次托福（话不能说死，不然明年的flag从哪来）
• CSDN博客阅读量能不能破百万，目前是43w（还是的努力持续写博客，不然按现有博客存量一年顶多10w的阅读增量）
• 自己写一门编程语言，名字我都起好了，就叫 U-lang U语言，U是Useless。
• 重新开始运营我的微信公众号，初步打算是公众号写非技术文章。没错，我还有个微信公众号，如果你是我CSDN博客上看到这篇文章，往左瞥一眼就能看到我公众号二维码了，欢迎关注。
• 腹肌恢复计划，又双叒叕一次重启。其实腹肌是次要的，主要是想控制住我日益增大的肚子和愈发油腻的脸庞。
• 我新买的吉他，还是学一学。。

结语

最后引用习大大的一句话“行百里者半九十，不可有任何松懈、麻痹和动摇”。 以下附上我之前几年的年终总结。
18年年终总结
17年年终总结
16年年终总结
15年年终总结
14年年终总结
13年年终总结

~谢谢打赏~

赏

　　赶在春节放假前写完我2018年的年终总结，虽然又晚了，但还是不能缺的。每次拖延都有很多的理由，这次主要是19年上班第一天喜提996，从此属于自己的时间又少了，哎，说到底其实还是自己拖延症犯了。
　　先概括下过去的一年，如果说17年是本命年水逆，那么18年算是水逆后开始转运的一年，但貌似也没彻底转过来。相比17年，18年的人生上没有什么太大的阻碍，但倒也不是顺风顺水，希望19年成为我顺风顺水 一路高歌的一年。
（更多…）

~谢谢打赏~

赏

　　17年的年终总结为什么起名叫『欢送本命年』呢！没错，17年是我本命年（毕竟我今年已经0x18岁了），发生了很多事让我相信有本命年水逆这回事，因为感觉17年是我人生中过的最不顺的一年，尤其是在工作上，感觉很坎坷，所以希望在新的一年里一切糟糕的事都成为过去式，让这些悲惨的回忆只存在于这篇总结里吧！
（更多…）

~谢谢打赏~

赏

　　Boss肯定要承担起leader的责任，但一个好boss并不意味着他是一个好leader。两年的工作经历，也让我看到了一些例子，比如有些团队业务并不差，但下面的人一个接一个的跑路，有些团队人员频繁流入流出，十几个人的团队两年来十几个人走十几个人。我觉得导致这种现象的原因除了团队方向有问题外，肯定和主管的脱不了干系。
（更多…）

~谢谢打赏~

赏

　　首先声明一点，我没怎么面试过别人，只是参加过几场面试，经历的面试官只有小20个吧，所以根本没有资格去评判一个面试官是不是合格的面试官。但经过我最近的一些经历，以及朋友做面试官的体会，再加上自己对面试的思考，形成了一个自己对面试官好坏评判的标准。其实也算是最自己将来面试别人或者被面试积累一些经验。提前声明，这里只是我个人的体会，不一定正确。
（更多…）

~谢谢打赏~

赏

　　这两年，因为各种机缘巧合，找到的三个比较不错的博客，分别是刘未鹏，阮一峰，斯科特.杨的博客，这三个博客都在持续更新，但刘未鹏的博客更新速度很慢，但都是十足的干货。其中最阮一峰的博客更新最快，涉及的内容也最杂，包括某个具体的技术、个人感悟、对未来的思考、杂谈等。斯科特杨博客是英文博客，主要是讲他理解的学习方法，平均每月更新3-4篇吧，我曾一度想把他每次更新的博客翻译成中文，无奈精力和能力有限，暂时作罢。
（更多…）

~谢谢打赏~

赏

　　工作两年，做运维两年，运维的岗位的地位急转直下，曾多次想离开，但一直都没好的的下家，直到最近终于离开了，工位没变，从运维都办开发，再彻底到纯开发。说实话，我离全职研发的水平还差一些，毕竟还是缺少一些完整的研发项目，但我在对架构理解对全局把控的能力应该是远超过普通开发工程师的，毕竟运维也不是完全白干的。
（更多…）

~谢谢打赏~

赏

　　第四年写年终总结了，哎，像我这种能坚持的人已经不多了，看下自己在15年年终总结里立下的目标，除去后来觉得没有太大意义的个别目标，个人以为年初目标完成度在90%以上。
　　我觉得年终总结无非就是三个大块工作、生活、学习。像我这种有进取心的人，最大头当然是学习了。让我们来挨个总结一把，首先从最次要的开始。
（更多…）

~谢谢打赏~

赏

　　在青岛第一次办的ACM/ICPC现场赛结束了，正是因为在青岛，我校ACM第二次进了现场赛，不过还是没有什么太好的结果，总感觉差那么一点，但一直说不清差在哪？但可以肯定的是绝对不是差在努力程度上。
（更多…）

~谢谢打赏~

赏

​　　写完正文，在纠结文章标题起个啥呢？　『正式入职一周年』『瞎扯淡』都太俗了，『写在工作一周年』感觉不是我风格。想了半天『mark一周年』，这标题不错，中英混杂，不失逼格，又能突入今天我正式工作一周年这个重点，尤其是『mark』一词，感觉真是独具匠心，还能体现出我的英文水平。
　　这周，阿里3000多员工搬进了望京新楼，我们整个大团队就在这3000多人里。再加上有几个同学入职阿里周年庆，10年 8年 5年，还有就是我们小团队合并到这个大团队，三件事合一起庆祝下，但重点是几位同学的周年庆。 他们谈了下在阿里5年8年 甚至10年都是怎么样的体会，另外还在自己主管、主管的主管坐在下面的时候被问了一个尴尬的问题。

（更多…）

~谢谢打赏~

赏

　　每天早上我做在走走停停的公交车上，看到旁边经过一辆又一辆的私家车，基本上上面只有驾驶位坐着一个人，我不禁在想，这又浪费了多少能量。大概算下，一个人80kg，一辆车一般都在2000kg以上，你一个人开车去公司所耗费的能量足够把20多人送到公司了（我承认这样算比较牵强，但我只想说明能源的浪费有多严重）。

（更多…）

~谢谢打赏~

赏

　　前两天在翻看quora的时候看到这样一个问题What are the characteristics of a mentally strong person? 英文拙劣的我尝试翻译一把，文中很多句子直译过来很晦涩难懂，所以在翻译过程中我做了适当的变通，使得更适合中国人理解，但我不保证不会偏离原文意思。
　　这里有个词 mentally strong，在中文中很难找到一个词和这个词匹配，直译『精神力强壮』似乎有些别扭，想到之前看过一本书《少有人走的路》，副标题是『心智成熟的旅程』，所以这里我把mentally strong翻译成『心智成熟』，我还是认为比较贴切的。以下是翻译内容。

（更多…）

~谢谢打赏~

赏

　　我年轻那会我也是朋友圈|QQ空间的常客，日均一条朋友圈，后来慢慢降低了发状态的频率。我已经看懂了发状态的套路，所以我开始不发状态。 接下来听我分析下朋友圈里的套路。我个人粗略的将朋友圈状态分为以下几类。。

（更多…）

~谢谢打赏~

赏

　　最近因工作上的变化，我所运维的200个应用即将交由其他团队运维，而我也会由运维转开发。已经一年多没写过代码的我重新拾起了我不是很熟悉的Java，主管也仅给我一个月的时间，期间还有其他乱七八糟一堆事。 在这种情况下，我只能寄希望于我是否能高效且快速地学习。从过去3周的情况来看，我在开发能力上的进步是可以达到我最初期待的水准。 另外这几周我也在总结自己在过去一年运维相关的文档（毕竟交接出去还是要把相关的事说明白的），同时也在看Google的新书《Site Reliability Engineering》、docker、zookeeper，还有坚持半年多的英语学习。 所以今天我会结合最近我一直在做的一些事来谈谈我对学习的体会。

（更多…）

~谢谢打赏~

赏

　　之前使用的是阿里云的php虚拟空间，可以只需要把wordpress包上传后就可以了，但感觉这样不灵活，虚拟空间也只能用来搭博客，不能干其他事。 所以我买了阿里云的ecs，其实就是一个远程linux虚机主机。 为了搭建博客，我必须安装配置php环境、ftp、apache、mysql等东西，踩了一部分坑，为了让大家少踩坑，特意在此记录我在ubuntu搭建workpess的过程，作为大家参考手册。

（更多…）

~谢谢打赏~

赏

　　想想我2015年还当了半年的学生，但实际上工作了9个月。首先说一下我15年我整年年的时间线，毕竟学生、实习生、正式员工的身份都有，还是有必要说说的。
　　14年12月份的时候到阿里实习，一直持续到15年1月底。为了过最后一个寒假，所以没有办离职然后提前回家了，在家过了整个2月份，看完了《明朝那些事》全册。实习前两个月都是在培训、学习、踩坑中度过，毕竟只知道linux关机命令的人是干不了运维的，但是到后来才发现我其实连关机都不会。。。。

（更多…）

~谢谢打赏~

赏

　　去年在阿里内推了50+份简历，最终仅有一人拿到offer，其中有部分人技术不差，但简历写的特糟，还有一部分人技术不行，简历压根没法看，所以去年写了这篇文章，在阿里实习生招聘开始之际改吧改吧再发出来，希望能给大家一些帮助。 文末附内推联系方式。。

（更多…）

~谢谢打赏~

赏

       刚刚大学毕业整一个月。大学这几年，尤其是后两年，看了很多书，现在在我豆瓣读书主页有149本的读书量了，其中有很多杂书，但也不乏好书，我就结合自己的体会从中给大家推荐一些。

       我个人大学期间参加ACM，所以计算机书籍会更偏向算法。另外因为开始对科学、数学有兴趣， 所以也会有一些这方面的书籍。为了拓宽知识面，我也看过一些心理学哲学的书籍，但本人并未在这些领域有所深入的研究。接下来我的读书重点会在英语、数学、机器学习等方面。 

       下面这些书只是结合我自身的情况推荐的，并不一定合理，可以适当参考下。推荐书目我会细化的学年，请大家根据自己的情况去阅读。

（更多…）

~谢谢打赏~

赏

从上一篇博客到现在，半年多过去了，主要是因为一件事：找到工作，并且实习了。在找到工作实习前确实有两个多月，也没写过什么博客，我觉得当时的原因就是因为自己觉得，为了找工作而做的努力都没有白费，放纵了两个月。然后就跑北京去实习了，在某大互联网公司实习，确实学到了很多东西。

实习第一个月，没多少钱，也没什么租房的经验，索性就租了一个床位，离公司是挺近的，但是环境很不好，各种各样的人，有来北京长期旅游的、有打工的、有送外卖的、有待业的、有发传单的、还有去给别人试药的……而且每天晚上特别吵，一直要闹腾到大半夜一两点，早上5点就有人醒了，20多个人共用一个卫生间，一个客厅住了十几个人，反正就是各种不方便。 来北京生活的等一个月，就体会到了生活的艰苦。还好，公司安排去培训，在杭州酒店住了9个晚上。很开心自己第一个月的工资可以让我换一个环境。

（更多…）

~谢谢打赏~

赏