1. 通过增加复杂性解决一个问题，会产生全新系统失效方式的风险

2. 多线程技术使应用程序服务器具有足够的容量扩展能力，来满足Web上最大站点的需求

2.1. 产生并发错误的可能性

3. 服务器的进程正在运行

3.1. 并不能帮助用户完成工作

3.2. 模拟客户端使用系统的体验，与真实用户是相同的

3.3. 该客户端无法进行合成事务，那么无论服务器进程是否正在运行，都可判断系统存在问题

3.4. 使用度量指标快速揭示问题，不必非要等到系统告警

3.5. 用外部监控补充内部监控

3.5.1. “系统崩溃”和“系统停止响应”之间区别

4. 多线程问题

4.1. 错误条件和异常会产生太多的排列组合，难以进行全面彻底的测试

4.2. 意外的交互可能会在先前安全的代码中引入问题

4.3. 运行时机至关重要，应用程序停止响应的概率会随着并发请求数量的增加而增加

4.4. 开发工程师从来不会为了测试而向应用程序发送10000个并发请求

5. 谨慎使用缓存

5.1. 滥用缓存可能造成新问题

5.2. 缓存能有力地解决性能问题

5.2.1. 减少数据库服务器的负载

5.2.2. 缩短响应时间

5.2.2.1. 将其控制在不进行缓存所用时间以内

5.3. 所有应用程序级别缓存的最大内存使用量，应该是可配置的

5.3.1. 不限制最大内存使用量的缓存，最终会消耗系统的可用内存

5.4. 缓存消耗了其他任务所需的内存，实际上会导致系统严重降速

5.5. 无论缓存上设置了多大的内存，都需要监视缓存项的命中率

5.5.1. 检查是否大多数缓存项已被使用

5.5.2. 命中率非常低，那么缓存就不会获得任何性能优化

5.5.3. 实际上还可能比不使用缓存更慢

5.6. 把数据保存在缓存中，其实是一次投注

5.6.1. 押宝“一次生成数据的成本，加上散列和查找数据的成本，不超过每次需要生成该数据时的所需成本”

5.7. 如果一个特定的缓存对象，在服务器的生命周期中只使用一次，那么缓存它就没有任何意义

5.8. 避免缓存特别容易生成的数据

5.9. 通过使用弱引用持有缓存项本身构建缓存

5.10. 任何缓存都存在数据过时的风险

5.10.1. 每个缓存都应该有一个失效策略，当其源数据发生变更时，能够在缓存中删除缓存项

6. 选择精心设计并经过验证的代码库

6.1. 构造可靠、安全、高性能的连接池，总是会比想象的困难许多

6.2. 所有的问题都可能潜伏在第三方代码的阴影中

6.2.1. 相比闭源程序库，更喜欢开源程序库

6.3. 程序库都是导致线程阻塞的源头

6.3.1. 如果是开源库，那么就可能有时间、技能和资源来查找和修复这些问题

6.4. 集成点附近经常出现线程阻塞

6.4.1. 线程阻塞和缓慢响应会创建一个正反馈循环，将小问题放大到系统的完全失效

6.5. 线程阻塞反模式是大多数系统失效的直接原因

6.5.1. 线程阻塞反模式会导致同层连累反应和层叠失效

6.5.2. 常见的系统逐渐变慢和服务器停止响应

7. 使用超时模式进行保护

7.1. 虽然无法证明代码不会发生死锁，但可以确保死锁不会一直持续下去

7.2. 避免函数调用中的无限等待，使用需要超时参数的函数版本

7.3. 即使意味着需要更多的错误处理代码，调用过程中也要始终使用超时模式