大家好，我是良许。
最近Linus Torvalds关于并行计算的言论再度引发讨论，初听震惊，细品后却发现老爷子的话颇有道理。
并行计算：看似美好，实则易入歧途
很多团队常陷入这样的误区：产品经理喊着做高并发系统，技术负责人便立刻规划分布式、微服务、消息队列，整个团队随即陷入协调、调试、排查分布式事务的泥潭。
三个月过去，复杂架构的系统还没跑通，而简单的单体应用早已上线产生收益。
这正是Linus吐槽的核心——并行计算并非线性提升性能的银弹。
你以为增加CPU核心、扩充服务器就能解决问题，实则80%的时间都耗在处理锁竞争、数据同步、死锁排查上，真正用于核心业务处理的时间不足20%。
不少大厂出来的架构师，上来就重构单体架构拆微服务，结果原本一个接口能搞定的事，要跨多个服务、多次RPC调用，还得兼顾降级、熔断、限流；调试时日志散落多个服务，排查一个锁相关的问题堪比当侦探。
那些踩过的并行坑：方向错了，努力全白费
我曾经历过这样的性能优化：老板觉得系统慢，团队里有人主张全面上多线程并行。
结果上线当天系统直接崩溃——核心瓶颈是数据库IO而非CPU计算，多线程不仅没解决问题，反而因上下文切换开销让系统更慢。
最终仅靠增加Redis缓存、单线程运行，性能就提升了5倍。
这印证了Amdahl定律：程序总有串行部分，这是性能上限，盲目堆并行根本解决不了本质问题。
很多团队把并行当成万能解法，却忽略了业务场景的核心痛点。
高手的选择：先做减法，再谈技术
我特别认同Linus的观点：优秀的程序员会尽量避免并行，非用不可时也会想清楚背后的原因。
真正厉害的架构师，不会上来就谈分布式、并行，而是先问清楚QPS、数据量，判断是否真的需要复杂架构。
一台配置合理的服务器加缓存策略，足以应对绝大部分场景。
Instagram早期仅几台服务器支撑上亿用户，WhatsApp靠Erlang让50个工程师管理数十亿条消息，他们靠的不是无脑堆机器、堆并行，而是对技术本质的理解。
反观国内不少团队，动辄微服务、容器化、服务网格，技术栈复杂到维护成本高企，一半人力都耗在救火上。
并行的正确打开方式：匹配场景与能力
当然，并行计算并非一无是处，关键是用对场景。
CPU密集型、数据无依赖的场景（如视频编码、图像处理、科学计算），天生适合并行；但IO密集型、数据强依赖的场景，优化算法、数据结构、加缓存远比并行更有效。
此外，团队能力也至关重要。
如果团队没能力驾驭分布式系统、快速定位并发问题，盲目上并行就是自掘深坑。
技术选型不是越新越复杂越好，而是要匹配团队能力和业务需求。
Linus的话虽稍显绝对，但核心思想值得深思：不要为了技术而技术，为了并行而并行。真正的技术高手，是用最简单的方案解决复杂问题的人。
下次想引入并行、分布式技术前，先问自己：真的需要吗？有更简单的方案吗？把时间花在有价值的事上，远比在并发坑里挣扎更有意义。
毕竟，我们写代码是为了改变世界，而非只做并发问题调试工程师。
