2019-12-23木桶理论那里举例不太适用每次只改一个参数的例子，木桶板属于同一个变量，基于控制变量法的思想，调整所有的木板也是相当于只调了一个参数作者回复: 我或许没讲清楚（应该多加一句来解释），我的例子的每块木板代表一个参数。
2- 2020-01-22踩过没有足够负载数据，命中缓存的坑。因此后来准备了10w个虚拟用户账号。
2019-12-30老师 我有在虚拟化环境下压测的问题：
"虚拟机硬软场景下的问题定位"
实际经验证明，现在虚拟化环境，当出现一个性能问题时(通过javacore等文件诊断）可能是一种假像，其原因是虚拟化并不是真正能做到资源的严格隔离,极有可能是别的机器正在运行大型的批处理或程序有严重的bug导致资源被无限制占用.
（示例：我们在虚拟机环境跑压力测试一场景，同样非上班时间点，发现有一天比平时要慢近10秒，后来到虚拟机管理员那才查到是虚拟群里另一台机器消耗了更多的cpu(其cpu一直处于报警状态，此问题如果不是每天用压测场景比较，很有可能就事论事定位错了，实际生产环境偶尔发生后，后续分析时，实际发生问题场景已不可重现）
同时业务系统潜在有问题的地方，也可能因为整体虚拟化环境资源充裕，而被掩盖.
（示例：同样一个sql有严重IO问题，因资源充裕，没被暴露，当数据库移至实体机时问题即出现）
问题是：虚拟化环境，通常部署各种系统，其业务访问峰值，后台跑批时间等都不可控，作为具体的业务系统，如何避免 只见树木不见森林？走入问题诊断的误区.
展开作者回复: 虚拟化和多任务里面情况很复杂，很多因素影响，比如OS机制，虚拟平台，Workload特性。我后面有一个章节是关于这方面的，一个具体的生产案例。虽然不能面面俱到，但希望能开阔思路。
1
2019-12-24有一个问题想请教一下各位？我们最近测试发现pthread_mutex_t会频繁进入native_queued_spin_lock_slowpath，导致系统CPU飙高，但是这种现象只出现256线程时，提升线程就不会出现，我在网上看到说是锁竞争激烈才会进入native_queued_spin_lock_slowpath，想不明白的是为什么只出现在256线程的时候呢？请教下老师或者各位同学有没有什么好的思路- 2019-12-23今天文章中提到的坑基本都踩过，针对之前踩过的坑，我们采取了两种办法避免重复踩坑，一种是能自动化检测的自动化检测，另一种是形成一种流程规范，针对流程中的每个点都有一些检查项，根据检查项提前检查来规避之前遇到过的问题。
没踩过的坑，这个点就说不准了。