牙齿真折腾。

周末回了一趟老家。看标题就知道去干嘛了，治牙去了。从小牙齿就不好，年纪轻轻就装了 4 颗牙套。。。这一次又是蛀牙，3 颗牙套最近松了，没什么注意，导致里面的牙齿细菌滋生，又蛀牙了，而且蛀得不轻，基本上已经坏死，只能根管治疗，然后重新装 3 颗牙套，一个牙套 1800 块，3 个就 5400 块。。。病不起。

一朋友前段时间他去洗牙，医生发现他有将近 10 颗牙需要补，这次他知道我要回老家看牙医，因为我在这个牙医已经看了十几年了，家里人都在他那里看，口碑一直不错，技术也过硬，所以他就跟我一起去看牙齿。他的牙齿外面看起来挺完整的，给医生看完，发现其实很多个牙齿都蛀了，但都是蛀一丁点，所以都需要处理，大概处理了十几个，补了将近一个小时，最后花了 2000 块。

有些朋友同事问我为啥不在深圳看牙医，有医保，可以报销。其实不仅仅是钱的问题，一方面是在深圳看医生相对来说比较困难，网上预约经常预约不到好的时间；另一方面是医生不知道技术怎么样？有人会问在深圳大医院肯定技术牛逼，这真不好说，高中因为咽喉炎以及胃的问题，看了大大小小的医生，真不见得在大医院的医生就很牛逼，并且老家这个医生很靠谱、技术不马虎、很是靠谱，以前的牙是他做的，坏了让他弄也比较好处理。还有一些是老家也不远，从深圳坐高铁 2 个多小时就到了。

我这副坏牙齿也不能给大家来介绍如何保护好牙齿，说了你们也不信，连我自己都不信。。。虽然我一直吃完饭就漱口，睡前也刷牙，但是还是没法保护好牙齿。那就给大家科普一下刚刚学习的知名刷牙方法：巴氏刷牙法

方法：

1. 握好牙刷：拇指前伸比“赞”手势；
2. 牙刷的方向要对准牙齿与牙龈交接地方，刷毛与牙齿呈 45-60 度角，定位好牙刷后，作短距离的水平运动，2到3颗前后来回刷约 10 次；
3. 刷牙步骤：右后方颊侧开始，刷到左边;然后左边咬合面、左边舌侧再回到右边舌侧，然后右边咬合面；
4. 刷后牙舌侧时：左手刷右边后牙舌侧，右手刷左边后牙舌侧；
5. 刷颊侧时：刷右边颊侧时用右手，刷左边颊侧时用左手；
6. 刷完上面牙齿，用同样的方法刷下面牙齿。

注意：

1. 刷牙颈部龈缘时，以 45 度角，做上下提拉颤动，不做来回刷
2. 刷牙早晚各一次，每次不少于 3 分钟。

巴氏刷牙法信息来自百度百科。

希望大家重视起自己的牙齿，让自己牙齿健康起来。我也要好好保护好牙齿，以后有亲身经历哪些好的措施再分享给大家。

LieBrother

今年的冬天有点“冷”。给大家来点实在的东西。

不知道大家在跳槽的时候是怎么做的？直接投简历面试？还是准备了一段时间，复习一波知识点后再投简历面试？

不管你是哪种做法，如果面试不通过了，你也需要去总结问题，这时候总结问题也有点讲究。下面就讲一下我自己的体会。

大三找实习和大四找工作，那会一直用云笔记，云笔记的好处就是云端同步，并且可以分类存储。今年年初经历了工作之后的第一个跳槽，跳槽之前复习了一段时间知识点，依旧采用云笔记去记录知识。发现了一个很蛋疼的地方，复习过后容易忘记，原谅我工作之后一直吃学校的老本，没有积累很多实践的经验，只能苦逼囤知识点。后面一好友做运营的，跳槽去了京东，和他交流了一番，他推荐用思维导图去准备面试的东西，并发了一份他用思维导图做的工作总结(其实可以说是简历了)。看到后非常震撼，而且一目了然，看了一遍就能把他的工作经历印在脑海中。

于是我开始使用思维导图来复习知识点，刚开始可能不是很适应，因为思维导图讲究的是层层深入，有时会怀疑这样子分层次对不对。现在回想起，这些都不是事，在写完发现层次不对，也就是你心里有更好的分层架构，那就改一下，写完之后，你会发现基本上知识点都已经记在脑海中了，而这思维导图，就是属于你自己的知识体系，你不会像以前一样，记住了琐琐碎碎的知识点，而是一张有层次、有主次、有内涵的知识体系。

可能有小伙伴要问：学习什么资料可以做思维导图？认真的回答：任何资料，任何你学习的东西，不管是看一本书还是刷一道题，你都可以把它归类到某个思维导图节点上。比如，你看了 MySQL 的书籍，里面介绍了索引知识，你记录了索引的知识点，有一天你看了一道题，讲的是索引的，觉得有价值，那么就可以把这道题加到你的 MySQL 思维导图的索引节点上。

下面弄一张自己做的思维导图给大家参考

希望大家能好好渡过这个冬天。Cai Yuan 阻止不了我们沉淀自己，最好的投资是投资自己。如果你也有比较好的学习方法或者工具，都可以留言分享一下。想要我整理的一些资料，也可以留言说一下。

LieBrother

今天介绍一下工作中会用到的 Git 分支模型。

先贴上图以表敬意

闲言

在学校不管是自己写课程设计还是给老师做项目，有 2 到 3 个人一起协作开发时就会使用 Git ，但是只是简单用了它所提供的代码协作功能，在学校的项目，比如课程设计，开发完老师检查完就没有维护了，给老师做项目也是，基于项目的特征：没有持久性、一次性开发，所以没有应到 Git 分支模型。在企业中，一个应用往往是有比较长的生命线，由很多个迭代项目开发构成，这时要解决几十甚至几百人的代码协作问题，就需要一套完整的规范的代码开发流程。

我还记得当初大四的时候，去了一家企业实习，当时小团队只有 3 个开发人员，git 使用没有规范，只有一个 master 主分支，项目也没有管理规范，来一个需求点就做。当时经常出现代码覆盖，各种代码合并，线上代码也不知道是哪个节点的代码。。。到我走的时候，也没使用上这个分支模型。毕业后入职了某银行，不说分支模型了，Git 都没用上，直到今年跳槽到互联网公司才了解到这个分支模型。因此，你工作不一定会真正用到这个分支模型，如果是在互联网企业，很有可能会使用上。

有些小伙伴看到这张偌大的图觉得有些晕，很认真地说，这是一张大家都在用的图，特别是互联网企业。如果是还没有工作的小伙伴，可能有些陌生，没事，我们来看一下这些内容。

分支介绍

master ：这个分支的代码是发布到生产的代码
develop ：这个分支的代码是预发布到生产的代码
release ：这个分支的代码是新版本发布到生产的代码
feature ：这个分支的代码是新需求开发的代码
hotfix ：这个分支的代码是紧急修复生产 bug 的代码

场景设想

下面列举一些可能你在工作中会经常面对的场景

1. 组长分配新需求下来，安排下周上线（假设是 1227 号），你看看当前有没有下周版本的分支？有的话很简单，checkout 下周分支（feature_app1.1.0_1227）来开发就行，没有的话这时需要新建分支，从 develop 分支创建新的 feature 分支（feature_app1.1.0_1227）,然后将对应的 pom.xml 版本号修改成 1.1.0-SNAPSHOT，注意命名，比如这里我用 feature 做前缀，你也可以自己设定一个规则。

2. 开发完 feature_app1.1.0_1227 需求，移交了测试，很遗憾，测试出现了 n 个 bug，这时依旧在 feature_app1.1.0_1227 上修复 bug。

3. 终于到了发版前一天，测试 MM 说 n 轮测试完了，没问题，拉上线版本，再做一次回归测试。这时，你就需要把 feature_app1.1.0_1227 分支合并到 develop 分支，然后从 develop 分支中创建新的分支 release_app1.1.0_1227，然后修改对应的版本号为 1.1.0-RELEASE。

4. 到了发版日早上了，测试 MM 用了 release_app1.1.0_1227 版本测试了一番，又发现了一个 bug。别慌，只要不是生产的 bug，都好解决。这时你要在 release_app1.1.0_1227 修复 bug，切记不能在 feature_app1.1.0_1227 上修改，feature_app1.1.0_1227 分支已经没有多大作用了，只用来看代码提交记录。

5. 安安全全的到了晚上，开始发版了，发完版突然发现了有异常，定位问题后发现是有一行代码写错了，跟组长确认后，在 release_app1.1.0_1227 分支上做了修改，重新打包后发版，验证了一段时间，没问题了。。。

6. 发版总算完成了，这时，别忘记把 release_app1.1.0_1227 版本合并到 develop 和 master 分支。还有一点很重要的，把 develop 分支代码合并到 1227 以后的版本（如果已经有1227 以后的版本的话）。注意：这个步骤合并代码要谨慎，如果有别人的代码合并冲突比较大，需要找那个开发的同事一起合并代码。总算可以睡个好觉了。。。

7. 告别了旧需求，迎来了新需求，接下来的需求开发就按上面的步骤走。。。

8. 第二天，突然生产上一直报 NullPointerException，定位发现是一行代码没有判空导致的，三番确认，原来这个数据以前是不为空的，现在确实需要支持有些数据为空的，需要紧急修复这个 bug，和组长确认之后，从 master 分支上拉了一个 hotfix_app1.1.1_1228 分支代码，修复了 NullPointerException，打包后上线，验证没问题后，把 hotfix_app1.1.1_1228 分支合并到 develop 和 master 分支，并把 develop 分支合并到 1227 以后的版本。

好了，一大坨的文字描述了基于分支模型开发的过程。不同公司在应用过程中可能会有些微小的不同，但是整体流程都是差不多的。比如有的公司可能会把 release 合并到 master 后，用 master 代码发布到生产，发版当时有异常，再从 master 分支上拉 hotfix 分支进行修复。上面描述的步骤就不一样了，发版时出现异常，直接在 release 上修复。这些小的差别就不用计较太多啦。

希望本文能够让你认识到有这么一个标准的 Git 分支模型，在不管工作上还是学习上，在需要分支管理的时候，回忆起有这么一个图，根据你的场景再应用进去，肯定会少走很多弯路。

今天给大家分享一次生产上遇到的内存问题。

生产上的一个应用经常运行一段时间后就内存告警，在一次告警中，先 dump 了内存下来，然后再重启了应用。

dump 命令：

1

jmap -dump:format=b,file=memory.pro {pid}

用 VisualVM 打开文件，看了一下，发现占用很高的是 java.nio.ByteBuffer[]，点击多层引用进去发现是 HBase 连接，看起来很明显，大概知道是什么问题了，有 6 万多个连接对象，肯定是连接未释放导致的。

到底是什么导致连接未释放？ 看了公司内部封装的框架代码，操作 HBase 有使用 HTablePool，配置了队列数是 10，这就奇了怪了。为啥连接数还那么高？

只能通过 HBase 源代码来看个究竟，直到看了 HBase 的 HTablePool#getTable()，取出为空的话还会自动创建 HTable，说明配置队列数不是固定死的，还会自动创建的。当 HBase 操作慢的时候，存 HTable 的队列很容易就为空了，这个时候会额外创建 HTable，这时候怀疑额外创建的 HTable 没有释放资源，再继续看代码。

既然可以无限创建 HTable，那就得关注下存 HTable 到队列的代码了。看了 HTablePool#putTable() 代码发现，只是简单判断了队列没满，就把 HTable 放到队列，多余的 HTable 竟然啥都没处理，就这样堆积在内存中。

看了 HBase 版本，是可怜的 0.89 古老版，在新的版本这个问题都不存在了，下面是 0.98 版本，已经解决了这个问题，把多余的 HTable 回收了。

这个坑也是公司一直没升级 HBase 导致的。所以要跟得上开源的脚步，尽量用高的版本的开源框架。在没升级 HBase 的时候，只能根据业务，把 HTablePool 队列配置配高些，才会减少自动创建的 HTable。

给大家来点福利

你看到的没错。。。就是 CSDN 下载积分。

以前学生时代，经常在 CSDN 找资料下载，苦于没有积分。记得刚开始很苦恼，很不爽，为啥要积分？后面自己上传了一些资料上去，都是设置为免积分，后来发现即使是免积分，有人下载就会得到 1 分奖励（现在应该没有了），欣喜若狂，把自己用过的一些资料发上去，因为都是免积分，所以积分一直刷刷的上去，后面 CSDN 改动了，默认把资料的积分都提上去，导致下载量没有那么大了，但到现在还是积累了 16563 分，已经足够用了。这么多积分，自己用的话肯定是用不完的，现在要刷分也比较难了。想了这么个主意，分享出来，大家有需要下载 CSDN 资源的可以发下载链接给我，联系方式：公众号或者邮件(liebrother8@gmail.com)，因为工作在身，肯定没法及时下载回复，有时间的时候，我会下载后回复大家。

LieBrother