仅从设计优化、服务拆分、自动扩容等方面进行优化，有时候并不能完全解决问题。比如，有时流量增长过快，扩容流程还来不及完成，服务器可能就已经抗不住了

在对记录更新操作或者(select for update、lock in share model)时，会对记录加锁(有共享锁、排它锁、意向锁、gap锁、nextkey锁等等),本文为了简单考虑，不考虑锁的种类。

事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔者读过一些Linux TCP协议栈的源码，就在解决下面这个问题的时候有一种非常流畅的感觉。

可以看到，技术圈的风向一直在变，大数据、云的热度已经在慢慢消退，现在当红的是 AI 和 IoT。这些火热的概念，它最终要从论文和 PPT 落地，变成真正能解决问题的系统，否则就是一个空中楼阁。那不变的是什么？(一些题外话的感触)

行锁就是按照行的粒度对数据进行锁定。锁定力度小，发生锁冲突概率低，可以实现的并发度高，但是对于锁的开销比较大，加锁会比较慢，容易出现死锁情况。

对很多开发者来说，数据库就是个黑盒子，你会写 SQL，会用数据库，但不知道盒子里面到底是怎么一回事儿，这样你只能机械地去记住别人告诉你的那些优化规则，却不知道为什么要遵循这些规则，也就谈不上灵活运用。

要想了解 Flutter，你必须先了解它的底层图像渲染引擎 Skia。因为，Flutter 只关心如何向 GPU 提供视图数据，而 Skia 就是它向 GPU 提供视图数据的好帮手。

我们有一家top级的淘品牌店铺，为了后续的加速计算，在程序启动的时候灌入她家的核心数据到内存中，灌入完成后内存高达100G，虽然云上的机器内存有256G，然被这么划掉一半看着还是有一点心疼的，可怜那些被挤压的小啰啰程序😄😄😄，本以为是那些List，HashSet，Dictionary需要动态扩容虚占了很多内存，也就没当一回事，后来...

第一，技术是分级的，具体说，是分短命和长寿的，也是分表面和本质的。我们要学习各种技术，但是我们要把足够的精力放到长寿的技术以及技术本质上。这就是第一个故事带来的启发。

策划反应服务器进不去,远程看了一下进程消失了(crash)，有时候也会出现能登录，但是无法执行操作(进程还在),无法被正常shutdown，进程根目录下出现了java_pid16298.hprof文件，一看到就是内存溢出了，觉得奇怪，应该不会是堆内存溢出，因为人数不多，初步怀疑是永久区溢出(Java8#Metaspace)，下面果然得到验证，因为启动...

规则引擎系统，在每次发版启动会手动预热，预热完成当流量切进来之后会偶发的出现一次长达1-2秒的年轻代GC（流量并不大，并且LB下的每一台服务都会出现该情况）