最近遇到一个客户现场发现的，表象是网络有问题，分析一圈下来发现是程序进入了某种死循环状态，耗尽CPU。
产品里的很多线程/进程的优先级设置的很高，甚至高过了内核运行程序的优先级，高过了产品内警告处理程序的运行，高过日志打印的程序。在这种情况下，如果这些个优先级高的程序出现问题，比如死循环，就会导致一个难题，而且会导致难题分析也比较困难。因为分析问题所依赖的警告信息与日志输出，变的非常不可靠；可能分析很长时间才能归结出真正的原因。并且问题是客户现场出现的，给问题分析增加了难度！
为什么会导致网络问题的假象，因为内核都没时间处理外部过来的网络包，所以有假像，说进来的包有延迟（缓存在了网卡及驱动）。
据传这个优先级的设置是前人二十多年前的设计。二十年间，平台一直在变迁，但是设计从未改变，遇到过类似的问题也有多起，但是每次都是浅聊，没有后文！所以我们面临的一个难题是：我们是否有勇气，改正前人留下的苦难源？因为产品的整体代码已经适应了这种不合理的设置（所以这种苦难源就会变得非常合理起来），如果要改变，需要做很多的回归测试，以及承担回归测试不完整的风险。这个问题，其实也适合很多的现实的社会现象！
所以最后一个问题是：大家是否有勇气干翻苦难源？还是会选择慢慢适应，变的中庸，并且传承，到更多的后人心中？
“To be or not to be, that is the question！”，经典的原因在于，有了“or”，才有了选择的机会，不管选择哪一个，都会变成我们的历史，变成我们的基因，变成我们未来的基石；但是选择的结果肯定不同，或者容易，或者困难；或者痛苦，或者快乐；或者前进，或者后退！
所以，是天注定吗？不是！是我们自己的选择！