《并发设计模式》第35章-线程池模式-服务器内存爆了！

作者：冰河
星球：http://m6z.cn/6aeFbs (opens new window)
博客：https://binghe.gitcode.host (opens new window)
文章汇总：https://binghe.gitcode.host/md/all/all.html (opens new window)
源码获取地址：https://t.zsxq.com/0dhvFs5oR (opens new window)

沉淀，成长，突破，帮助他人，成就自我。

• 本章难度：★★☆☆☆
• 本章重点：初步了解线程池的应用场景，重点理解线程池模式的核心原理和应用，并能够结合自身项目实际场景思考如何将线程池模式灵活应用到自身实际项目中。

大家好，我是冰河~~

为什么每个请求都要创建一个线程，这特么谁写的代码？老子想干死他狗日的。小菜拿到代码后，心里一万个“草泥马”在奔腾，这简直就是瞎写啊，怪不得CPU会爆掉。此时，修复这种问题对小菜来说，已经不算什么难事儿了，于是小菜三下五除二修改了代码。。。

一、故事背景

这天小菜早上刚到公司，就被告知生产环境社区电商系统的优惠券服务内存和CPU占用都非常高，服务器撑不住了，一度处于假死状态。小菜赶忙拿出电脑，拉取后排查问题，这不看不知道，一看吓一跳。为什么每个请求都要创建一个线程？这特么谁写的代码？老子想干死他狗日的。小菜看完代码后，心里一万个“草泥马”在奔腾，这简直就是瞎写啊，怪不得CPU会爆掉。此时，修复这种问题对小菜来说，已经不算什么难事儿了，于是小菜三下五除二修改了代码。

二、案例场景

在小菜公司实现的社区电商系统中，当用户成功下单后，会给用户发送积分和优惠券，并且会通过消息推送的形式告知用户：“恭喜您获得一张XX元的优惠券”。像这种消息推送，一般在大厂都会有单独的消息推送服务，只需要业务系统对接消息推送的接口即可，整体流程如图35-1所示。

可以看到，忽略掉技术实现的技术，在社区电商项目中，消息推送的流程还是比较简单的。当订单服务调用支付服务发起支付请求，支付服务支付成功后，会回调订单服务的接口来同步支付状态，或者订单服务会调用支付服务的接口查询支付状态，如果支付成功，则订单服务会调用积分服务和优惠劵服务向用户对应的账户增加积分和优惠券，增加积分和优惠券成功后，就会调用消息推送服务，向用户的手机APP推送消息通知。

如果是让你设计和开发这个推送消息服务的流程，你会怎么设计呢？其实，大家不难想到，推送消息大部分场景下都是调用第三方推送服务，或者公司专门的消息推送服务，这就涉及到网络交互的问题，网络本身就是不稳定的，如果是同步调用的话，那性能肯定就比较低，如果下单的用户比较多，那性能问题就会更加突出了。再加上给用户推送消息通知，对于整个交易链路来说，其实并不是太核心的业务。所以，我们可以对消息推送服务进行异步化设计，没错，小菜所在的公司也是这么做的，不过在具体的实现过程中，每条消息都会开启一个新的线程向客户端进行推送，如图35-2所示。

这种只要有用户下单支付成功后了，为用户增加积分和优惠券成功，就创建一个线程为用户推送消息的方式可行吗？我们继续分析。

三、代码复现

这里，为了更好的让小伙伴们在脑海中复现出代码的执行逻辑，这里，我们就模拟一个简单的代码案例，主要就是模拟实现每条消息使用一个线程来进行推送。具体代码的实现步骤如下所示。

查看全文

加入冰河技术 (opens new window)知识星球，解锁完整技术文章与完整代码