用断言做逻辑判断

操作视频

（暂无）

说明

上个月跳槽到了现在的公司，这里的架构师推荐的一个做法让我新奇又怀疑：用断言来做业务逻辑的判断。
这位架构师的说法是这样的：我们的系统有2种异常，系统异常和业务异常。比如登录操作，如果密码不对，那就是密码不对异常！
断言抛异常我们一般都只用来做测试，用来做业务我还真没想过。
这样做的好处就是代码会变得很简洁，因为只处理我们认为成功的情况！所有不成功的情况，抓住了就抛异常！
当时我问这样做对性能会不会有影响，架构师的回答是不会！原因是api接口服务，首先对单个请求速度的影响在毫秒级，对用户来说几乎没没有任何体验上的影响；另外对并发量也不会有影响，因为请求是多线程的！
但是我问有没有做压测时，他们也没有做！那我只好自己试下咯！

测试环境

腾讯云标准型S3，2核 4GB 3Mbps，CentOS 7.6。
（本来是在我本地的电脑win7上测的，但是结果很不稳定，最后改在云服务器上测）

测试接口项目

放到github上了：https://github.com/dabintang/SomeExperiments
就是一个很简单的模拟登陆的接口，没有用到数据库什么的，就是直接判断传入的登录名和密码是不是指定的一个值而已。

用jmeter做压测压测

100个线程同时调用一次的结果：
正常登录测试结果（没抛异常的情况）：

异常登录结果（抛异常的情况）：

1000个线程同时调用一次的结果（测试3次取中间成绩的）：
正常登录测试结果（没抛异常的情况）：

异常登录结果（抛异常的情况）：

2000个线程同时调用一次的结果（测试3次取中间成绩的）：[本来想测10000的，但是我这服务器不行超时太多了，2000都超时很多了！]
正常登录测试结果（没抛异常的情况）：

异常登录结果（抛异常的情况）：

结论

可以看出来，当并发量大的时候还是会有比较明显的影响的。当然如果机器好一些，或者做了集群会好些，但在更高的并发量它还是会有明显的影响！毕竟我们的电脑没有无限的资源，并发量上去了总是会发生没有资源了要等待其他任务释放资源的情况，而抛异常来结束请求的做法会让请求的结束变慢，哪怕只是一点点最后总会影响并发量！
（以上结论只是我个人的猜测，由于知识有限不一定正确！）