本应该每年的年末时做一年的总结与新年的规划，但今年特别能拖，连续拖了几个月才开始落笔总结，罪过罪过。2018已过，我已步入而立之年，这一年，对待自我和这个世界有了一些不一样的地方，也许这就是长大，越长大越孤单，不再依赖别人，开始成为别人的依靠。有人说人生的底色本身就是凄凉的，当活着时就应该最求热爱以及美好的实物，说来容易，做起来却无从下手，到底什么是自己热爱而又美好的事物值得自己追求呢，思索良久，竟无答案。

雷·达里奥说: 如果你不觉得一年前的自己是个蠢货，那说明你这一年没学到什么东西。 more >>

发现问题

3月8日收到线上部分区域监控系统报警，提示数据处理服务大批异常报警；登录机器查看系统负载情况：

系统CPU占用并不高。

同事提示，发现了HSF日志中输出了HSF连接池满的情况：
more >>

为什么需要架构可视化

随着企业进行微服务架构改造，系统架构复杂度越来越高，架构变化日益频繁，微服务改造后的实际架构模型可能与预期已经产生了巨大差异，架构师或系统运维人员很难准确记忆所有资源实例的构成和交互情况；其次，系统架构在动态演化过程中可能引入了一些不可靠的因素，比如弱依赖变强依赖、局部容量不足、系统耦合过重等，给系统的稳定性带了极大的安全隐患。所以我们每次在面对系统改造、业务大促以及稳定性治理工作之前，都会通过梳理架构图的方式，呈现系统架构中个组件之间的交互方式，架构可视化能够清晰的协助我们识别架构中存在的问题以及建立高可用的系统。 more >>

背景

业务上有一个需求使用基线数据中拷贝出内容，分发到不同用户集合的存储实例中，使用模型标识就是B->(u1,u2,u3…uN)，初始代码逻辑是，每个用户都有单独的定时器触发来执行B->uN的拷贝，执行这个过程需要首先从基线B中取出数据，然后替换为uN的用户信息，在写入uN的数据存储中（用户之间逻辑隔离非物理隔离），期初此流程没什么问题，后来考虑到每个用户读取的基线可能相同，可以对基线数据做local cache，以此来优化程序的执行性能， local cache 变量为全局共享变量，多线程可访问。

问题

在做性能优化使用local cache的时候，会先查询缓存是否存在，如果不存在，则查询基线数据，如果查询的基线存在的话，则回写到缓存中，并向目标用户实例中写入基线数据，整体流程如下： more >>

前段时间百无聊赖之际无意翻阅到一部日漫《十二国记》，看之前我先翻了翻豆瓣评价（下意识的去评估投入产出比），评价的人不多，但是很多评价说儿时的这部日漫奠定了自己的人生价值观以及世界观，我随之着了迷，到底是一部什么动画有这么大的魔力？

在看了前几集的略显拖沓的情节后，越发后面越来越精彩。看到女主从一个柔弱的女高中生，在不断面对自己内心的批判与挣扎中变得越发强大，看到了活在自己痛苦之中的铃，看到也不知道为什么而存在的浅野，其中有很多让人深思的对白，从这部动漫的各个人物角色中，总能找到那个似曾相识的自己。

活出自我

我从小就是那种乖乖孩，周边几乎所有的亲朋好友对我的评价基本都是“听话、懂事”，无论是在学校与老师、同学的关系，还是在家与父母亲人的关系，我都处理的很融洽。我曾一度认为这是自己处事得体的结果，看到了阳子面对自我的时候，才知道了原因。阳子像画出来一样的优等生，私生活和家庭都很踏实，和同学的关系十分友好，老师们也很喜欢她，不过一般来说这种事是不可能的，对老师来说都额好孩子，在同学间就会被梳疏远，在朋友心中受欢迎的话，在父母看来就像是走上了歪路一样，每个人眼中看起来都好的孩子，往往只是为了让别人认同自己而丧失了自我，一味地迎合别人而已。 more >>

早上起床后，悠然自得地在阳台上晒着太阳看着柴静的《看见》这本书。突然楼上吵架吵的甚是厉害，这已经不是第一次听到楼上吵架了，每次都是伴随着咕咕嘟嘟的物品跌落到地板上声音、妇女歇斯底里的呼喊声、小孩声嘶力竭的哇哇哭闹声、间歇性的愤怒的男性咆哮声。

这一次吵闹的比之前几次都要凶，我感觉不太对劲，打开门，走上楼梯，准备去帮他们和解一下，心想：毕竟是一家人，没必要闹到这个份上。当我走到楼上时，女主站在门外，朝着门内哭喊道“你为什么打我，我出来没有打过你，你为什么打我”，他们的门没关，我看到他们玄关的台面上堆满了书籍，放不下的书籍已经被实实在在的塞在了竖立起来的书层上面，想必也是一定程度上的知识分子，我刚准备去拦架，就听到女主对着门外吼道：“我是在受不了你了，你给我走”，听到这些，我的脚步迈不开了，感觉自己想好的劝解的话不一定能凑效，反而可能让他们觉得不堪的场面，此刻他们需要的是冷静，然后控制住自己的情绪。

我重新回到阳台，继续翻看书籍《看见》，正好看到讲述十几位女性因为无法忍受自己的丈夫而杀害丈夫的故事，调查中的大部分女性都是在无数次沉默忍耐之后才爆发了最后的还击。我从小也经历过父亲喝醉酒，发了疯似的，拿着砍刀要杀人，当时母亲哭泣着抱着我躲在房间的角落里，我至今还清晰的记得那门框旁边残留的被刀砍下的凹痕；母亲的性格是那种凡事都隐忍，不主动把事情摊开来说的那种，我之前还嘲笑母亲懦弱的性格，后来我才明白这是“恐惧留下的阴影”，一个没有当过弱者的人，不会体会到这种恐惧。那些女犯人之所以环击，正是因为恐惧的一层层积累，积累到一定程度后，就会以暴力的方式爆发。

“叮咚，叮咚”，一阵门铃响声打断了我的思绪，我打开门，看到是天猫超市的配送员，他说打我手机没人接，担心我家的东西又丢了，现在都不敢放门口了，听到楼上的吵闹神，他说：“我也是离过婚的人，一个人来到异地杭州，无依无靠”。我不知道该说回答他，脑子中对婚姻这件事有了缕缕疑惑。

楼上的声音渐渐消停了下来，我也看到这篇报道的结尾了，结尾处柴静写到“他人经受的，我必经受”。在最近的几年里，我愈发的明白一个道理，那就是：不要随意地站在自我的立场上使用自己那有限的人生经历去揣测与评判别人的人生，我们不曾经历过的一切都让我们的评论显得格外肤浅。

此时，老婆问我，“我们如果吵架了，你会怎么样？”，我笑了笑。

从事软件编程已经长达8年之后，曾经中间有很长一段时间感觉自己的技术能力没有得到根本性提升，与那些优秀的同龄人相比，技术自卑油然而生，面对日新月息的技术变更和时不我待的岁月流逝，步入中年的我不得不变的焦虑起来。回顾自己的编程生涯，刚毕业的头几年，通过自主学习实现了编程语言的基本掌握，紧接着使用学到的技术完成各种项目，然后日复一日，有时候也会看看技术书籍，但是终究未能突破语言层而知晓技术背后的本质。而后通过长时间的摸索与交流，寻找到了一些解决技术人技术焦虑的方法，这些问题和方法更多的是一种思维方式，一种看问题的视角，希望这些建议能够让我们有所收获和思考。

技术焦虑的起因

技术热情变低

有人说：职业倦怠是做了大量重复劳动缺乏调整，或者努力完成高风险问题最后却以失败告终而导致的。在软件行业，接触了很多人，发现一开始大家对技术都非常热情，当把它编程职业后，时间一长，就索然无味了，但是又不得不从事这个行业，毕竟还要养家糊口。缺乏热情，可能是我们进入了瓶颈期，在大量重复劳动当中，自然提不起什么兴趣。我们可以有两种方法破局：1. 主要要求承担自己感兴趣又没做过的事情。阿里有一句老话，“今天最好的表现是明天最低的要求”，我们要时刻突破自己所在的“舒适区”，让自己跳跃到“学习区”。2. 为自己而工作。为别人工作就很容易消耗的我们的热情，如果我们转变思路，把学习工作转变为为自己工作，就会有所动力。我过观察到的是，那些在专业领域上付出了极大热情的人，往往因为这个工作领域的投入而成就了自己的影响力，难道这不是在为自己工作，为自己打造信用背书，为自己打造个人品牌吗。 more >>

Mybatis的本质：混合型Java对象持久化工具；

前置说明：

需要提前具备SQL、JDBC、RDBMS、XML、OOP等知识；

什么是Mybatis：

核心点：

• 支持了SQL、存储过程、对象/关系映射的持久化框架；
• 消除了几乎所有的JDBC代码和需要手工处理的参数和结果；
• 支持XML和注解两种方式来配置sqlmap、mapper、pojo三者之间的关系。

Mybatis理念：坚信SQL、RDBMS将继续使用30年；： more >>

通常的POJO对象setter方法return 为void

1
2
3

public void setStatus(String status) {
    this.status = status;
}

但是面对对象属性填充时，一堆的set方法让代码看起来很臃肿，部分同学采用类build模式，对setter方法进行改造，改造后就可以使用链式处理简化属性设置；

1
2
3
4

public Employee setName(String name) {
    this.name = name;
    return this;
}

流式编码风格如：

1

new Employee().setName("Xin yuan").setHeight(178);

有人认为这让pojo方法设置变得更加便捷，有其使用之处，但是也有人认为return this打破了Java Bean的规约，破坏了每个函数单一职责的原则，也可能会破坏一些工具库的使用，或组织JVM做一些优化。而且在IDE中getter&setter的自动生成内容中并没有“return this”。综其所述，setter方法“return this”并不建议。

当然还有其它选择方案：

方法一：

采用java内置语法：

1
2
3
4
5
6

new Employee()
{{
    setName("Jack Sparrow");
    setId(1);
    setFoo("bacon!");
}});

方法二：

采用更加复杂的内部类builder模式：

1
2
3
4
5
6
7
8
9
10
11
12

public Employee setName(String name) {
    this.name = name;
    return this;
}

public static class Builder {
    private String name;
      public Builder name(Strig name) {
        this.name = name;
        return this;
    }
}

造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。但是一般POJO 类都比较简单，非复杂对象，所以采用builder模式并不会让代码变得简洁，反而会显得更加臃肿。

方法三：

属性新增withXxx方法：

1
2
3
4
5
6
7
8
9
10
11
12

public Employee setName(String name) {
    this.name = name;
    return this;
}

public Employee withName(String name) {
    setName(name);
    return this;
}
//使用方式
new Employee().withName("Xin yuan").withHeight(178);

结论：

不建议在POJO： Java Bean的setter方法中添加‘return this’，我们遵循Java规范，如果期望简化Java Bean的属性设置，可以采用with或build方法。

参考：

https://en.wikipedia.org/wiki/Plain_old_Java_object

https://stackoverflow.com/questions/1345001/is-it-bad-practice-to-make-a-setter-return-this