学习心得

本篇主要是思想总结，没有技术干货，只是一些底层知识的学习感触。

神隐

在面临一些海量数据处理的时候，计算机的处理速度也会很长，这可能导致我们系统出现一段时间的不可用，或者表现在用户端就是突然间的卡顿。

回想到之前学习过的框架也好，底层算法也罢。对于此类问题有个统一的解决思路-------拆分过程

这些东西目前在我脑海里还很抽象，我尽量举一些例子具象化。

redis中的hash结构，它有一个扩容机制，当负载因子达到一定数值，就会触发hash的扩容，但是如果此时 hash 中的数据量已经非常大，扩容操作将会耗费大量的时间，此时redis会处于不可用的状态（redis单线程处理客户端请求），而redis则采用了 渐进性 rehash的方法。

• 先创建出扩容后的hash
• 然后慢慢的把旧hash中的数据往新hash这边搬（搬一会儿，停下来做其他的事，然后又过来搬）

而反应到用户这边，我们并不知道，就好像用户正在上课的老师，而redis就是在下面搞小动作的学生，老师转过头来，它就停止搞小动作，专心听讲，老师转过去，它又搞小动作。

而在CMS垃圾回收器里也有所体现，GC过程中是存在一个 STW的状态，也就是所有用户线程被暂停。而这个时间随着垃圾回收的用时增加而增加。

当STW的时间过长时，用户这边就会表现出系统卡顿的现象。而 CMS 也是以搞小动作的方式进行了时间拆分。

• 暂停一会儿，我GC一下
• 开启用户线程，跟我GC一起玩
• 再暂停一下，等我搞搞小动作
• 再开启，跟我GC一起玩

或许我们本应该 STW 0.5秒，但是这样一拆，假如每次就 0.1秒的暂停时间。用户这边卡顿现象就很微弱。

这样把原本应该花费的时间进行拆分，而让用户根本感觉不到的操作。前人的思想值得敬佩，真·神隐之术。

拆东补西

虽然平时说拆东墙补西墙经常是作为贬义词，但是运用在一些场景中，便是智慧。

尤其突出的就是并发问题中的 CAP 原理。我们只能得其二，不能全都要。那这个时候就要考虑了，我们到底要什么。是强一致性？是高可用性？还是分区容错性？

如果我们要保持强一致性，那么在很多场景下，直接加锁，妥妥的线程安全。但是，并发数一上去，处理时间就大大延长，用户得到反馈的时间又大大增加，可用性大大降低。

凡事结合实际需求，今天是西墙那边起风，那就该去补西墙。明天是东墙漏风，那就该去补东墙。

并发场景中处处体现均衡之道。