《并发设计模式》第18章-承诺模式-这代码性能怎么这么差！
作者：冰河
星球：http://m6z.cn/6aeFbs
博客：https://binghe.site
文章汇总：https://binghe.site/md/all/all.html
源码获取地址：https://t.zsxq.com/0dhvFs5oR
沉淀，成长，突破，帮助他人，成就自我。
- 本章难度：★★☆☆☆
- 本章重点：了解承诺模式的使用场景，重点掌握承诺模式在实际项目场景中的应用，并能够结合自身项目实际场景思考如何将承诺模式灵活应用到自身实际项目中。
大家好，我是冰河~~
在开发过程中，你是不是遇到过这样一种场景？项目中存在业务关联性不强的业务，这些业务在一定程度上可以并行执行，而不必按照串行的方式依次执行。并发执行这些业务关联性不强的业务，能够提升系统运行的并发度，提高系统的性能。
一、故事背景
作为程序员界一枚吃苦耐劳、积极上进的超级新秀，小菜不仅会主动做好公司的产品，在实现功能的过程中，如果有不会和不了解的知识点，以及解决不了的问题时，都会向自己的直接上司老王求教，凡是老王讲过的技术和知识点，小菜回到家都会自己认真复习和总结，并且会主动深入思考如何将学到的知识进一步灵活应用到实际项目中。
这天，小菜又接到了一个新的需求，就是在公司新开启的社区电商项目中开发用户下单和支付的业务逻辑。虽说小菜没有开发社区电商项目的经验，但是凭借着自己之前对于技术和知识的积累和总结，这点小功能对他来说根本不在话下，在小菜的一顿操作下，完成了功能开发。
但是，在测试的过程中，又出问题了：这代码的性能太差了，根本无法发布到线上生产环境。被测试打回后，小菜又陷入了无穷的排查问题中，无论小菜如何排查和调试代码，都无法找出问题所在。
“明明这么简单的逻辑，实现功能后性能会这么差？不应该呀！”，小菜在心里嘀咕着，随着时间的推移，小菜的心情也变得有点急躁了，“卧槽，这特么到底是哪里出了问题，性能不应该这么差呀”。本来小菜心里想的是自己独立完成这些功能，并发布上线，没想到又在项目的性能上栽了跟头，看来还是要向老王求助才行。于是，小菜站起身，向老王的工位走去。。。
二、求助老王
小菜来到老王的工位旁，说到：“老大，可以帮我看看我写的代码吗？我实现了用户下单、支付、发送积分和优惠券的逻辑，功能是实现了，但是测试的过程中发现性能很差，我排查了半天问题，也调试了代码，实在找不到问题出在哪里了，可以帮我看看吗？”。
老王看了一眼小菜，说到：“可以，走，我看看你写的代码”。
老王和小菜一起来到的小菜的工位，老王坐到小菜的位置上看起了小菜写的代码，仅仅几分钟的时间，老王就发现了代码的问题，于是对小菜说：“这代码确实有问题，这么写性能肯定提不上来”。
“啊？我没看出来啥问题，我都调试半天代码了，确实没看出问题来，哪里出问题了呢？”，小菜很疑惑的问到。
“这样吧，我还是给你系统讲讲吧，这个问题会牵扯到另一个并发设计模式，也就是承诺模式，也叫做Promise模式，走，还是去会议室吧，我给你讲讲”，老王说道。
“好的”，小菜回应到。
于是，小菜跟着老王一起拿着电脑，再次走进了会议室。。。
老王来到会议室，将自己的电脑放到桌子上，便开口问小菜：“以前听说过Promise模式吗？也就是承诺模式”。
“这个没有听说过”，小菜回应到。
“好，我们先不讲Promise模式，我先给你分析下你代码的问题吧”。
“好的”，小菜继续回应到。
“为了方便你更好的理解问题所在，这里，我按照你的思路写个案例，基于这个案例代码，我给你讲讲问题所在，后续我再给你系统的讲讲Promise设计模式”。
“好的”。
“在正式写代码之前呢，我们先来简单说说要实现的案例的功能”，于是老王便吧啦吧啦的说起来。。。
三、模拟案例
为了小菜更好的理解出现问题的根本原因，老王为小菜画了案例程序的代码结构图，编写了代码实现，并为小菜讲解了为何程序会性能低下的原因。
3.1 案例结构
要实现的案例程序其实也比较简单，就是模拟用户下单并支付成功后，给用户增加积分和优惠券的逻辑，为了小菜更好的理解案例代码的结构，老王还是为小菜画了一张类结构图，如图18-1所示。
通过上面的类结构可以看出，这里的案例程序代码比较简单，类结构关系也比较清晰，这里就不过多的赘述类结构的关系了。
3.2 实现代码
画了案例的代码结构图，老王便开始打开研发环境实现案例代码，此时的会议时异常安静，只听到老王噼里啪啦敲键盘的声音。。。
查看全文
加入冰河技术知识星球，解锁完整技术文章与完整代码
