胡凯旋的个人技术博客

下载源码在这个github仓库上可以下载到各个版本的源码使用Intellij Idea打开项目假设你下载了001版的zip压缩包“shopOrderTest-001.zip”，解压之后得到了“shopOrderTest-001”文件夹。然后就可以使用Intellij Idea打开项目了。Intellij Idea的版本推荐使用2018年以后的版本。打开项目操作如下图所示： ...

概括总结“并发线程数量”与“每秒能提交的订单数量”之间并不是线性的关系，当达到某个临界值以后，线程的增加对性能的提升就不明显了，甚至会降低性能。至于“临界值”是多少，不同的电脑应该是不一样的。我这次测试的线程临界值是365左右。005版本更新说明把单线程改为多线程。不同的线程数量需要分别来测试，有两种方式可以执行测试，第一种是把所有的测试写在同一个类中，用方法来区分，一开始也确实是这...

概括总结这一版本写了两个测试类，一个测试类中查询全部字段，另一个测试类中只查询必要的字段，然后对比性能。结论是：根据是减少的字段的长度不同，性能会不同。具体请查看下面的测试结果。013版本更新说明这个版本的改动很简单，Version013FullColumn.java 中的三个查询SQL语句中一共查询16个字段， Version013LessColumn.java 一共查询10个字段（其...

概括总结提交订单时有3个对数据库有改动的操作，当3个操作一起提交时，比3个操作分别提交的性能要高8.40%。014版本更新说明提交订单时对数据库有改动的操作有：第5步：保存订单到数据库中，并返回订单ID第6步：保存订单商品到数据库中第7步：更新商品的库存与销量这个版本的改动很简单，在Version014SeparateCommit.java中演示了3步操作分别提交。 在Versi...

概括总结在电商下单时，一般都需要选择收货地址。这时候，在页面显示的信息已经包含手机号、姓名、详细地址、地址ID等信息了。那么这时候可以有两种选择，1、只把地址ID作为参数传过去，后台根据ID重新查询地址对象，对对象中获取详细信息； 2、把手机号、姓名、详细地址作为参数传过去，后台不需要查询数据库，直接使用前台传来的参数。这两种方式的性能差异是：“传参” 比 “根据ID查询” 性能好3.65%...

概括总结这一版测试把商品信息存在内存中，而不是每次都查询数据库。结果是：查询缓存比查询数据库的性能好5.28%。016版本更新说明Version016NoCache.java：没有缓存，查数据库的版本。Version016WithCache.java：直接查询缓存的版本。GoodsCache.java：简单的商品缓存类。测试结果统计10次测试的平均值之后：Version016...

概括总结Java8的parallelStream并发流能达到跟多线程类似的效果，但它也不是什么善茬，为了得到跟上一版本的多线程类似的效果，一改再改，虽然最后改出来了，但是还是存在理解不了的地方。006版本更新说明上一版本中写了多个测试类，每个类针对一个线程数量。写这一版的时候觉得上一版本有点太傻了，于是花了点时间想了想办法，发现确实可以在一个类中完成。也证明了上一版的写法确实是傻。把...

概括总结int(10)类型的性能比long(20)类型的性能好4.01%（差别不明显）。017版本更新说明这一版本有两个SQL文件：Version017IntegerId.sql：其中的ID都是int(10)类型的Version017LongId.sql：其中的ID都是long(20)类型的另外一个比较重要的改动是，之前的版本是测试10次，然后取平均值；这次的版本是测试12次，去掉...

概括总结在用到synchronized关键字的时候，凭直觉就会加在方法上，比如public static synchronized void test(){}，但是这种直觉不见得是对的，估计大部分时候是出图方便，想偷懒，才直接加到方法上的。推荐的做法是：仅仅只同步需要同步的代码。009版本更新说明这个版本主要是对比以下两种代码的性能：（代码为伪代码）第一种：整个方法同步public ...

概括总结引入FutureTask能提高并发度，相应就可以提升性能，这次测试的结是，提升了38.93%（参考值）。它的缺点也很明显，就是增加了代码的复杂度，不方便阅读了，且对异常也要额外处理，而且大家对FutureTask也不是很熟悉。衡量利弊之后，我觉得是值得引入的。012版本更新说明这一版本找到了一个办法来消除测试方法执行的顺序带来的误差，即：使用一个随机数来判断先执行哪个方法。代码见...

概括总结在这个版本中，把提交订单的方法设置成public static synchronized的，与仅仅是设置public synchronized的，在提交订单的性能上有什么差别？答案是：没有明显区别（是同样的差）。008版本更新说明复制出了一个文件，如下图，其中Version008Static类中的提交订单方法是public static synchronized的，Version...

001版本的github源码在这里，如果不知道怎样运行项目，请参考这里数据库表设计一个大的电商平台的下单是非常复杂的，不同行业的业务也可能不一样，由于这个系列只是想研究性能优化相关的问题，对业务要求不高，因此简化成了以下几张表。 表中的关系可以这样形容：一个“用户”购买“商品”时，选择一个“地址”用于收货，然后提交了一个“订单”，考虑到可能会同时购买多件商品，因此需要有一张“订...

准备用1年左右的业余时间，研究一个基本的“提交订单”功能的正确性和并发性受哪些因素影响。这些因素包含以下几大方面：硬件配置、数据库配置、Java代码配置、集群环境配置。具体来说，我目前考虑到的可能的因素有以下这些：硬件参数，如：普通硬盘、普通SSD、高速SSD数据库的类型，如：Mysql、Tidb、SqlServer、Oracle等数据库参数，如：最大连接数、缓存大小等数据库表...

概括总结使用hikari数据源之后，相对于第003版的druid数据源，从提交订单这个复杂的操作上来说，性能提升了17.79%。而从获取数据库连接这一简单的操作上来说，hikari比druid优秀几百倍。004版本更新说明pom.xml文件中引入了新的jar包：<!-- HikariCP数据库连接工具 --><dependency>

002版本的github源码在这里，如果不知道怎样运行项目，请参考这里数据库连接池对性能的影响总是在各种地方看到类似的说明：“数据库连接池是非常昂贵的资源。” 那么请问“非常昂贵”到底是有多昂贵呢？在我的机器上的测试结果是：从数据库获取一个连接的平均耗时大约是3到4毫秒。这次不依赖框架自带的连接池以后，试着自己写了一个简单的数据库连接池，参考了这篇博客：javaweb学习总结(...

概括总结在一个public static的方法上加上synchronized关键字以后，相当于回到了单线程的状态，性能直线下降93.61%，一夜回到解放前。007版本更新说明在原来的submitOrder方法之上增加了一个submitOrderSynchronized方法，在测试时，分别调用这两个方法，统计耗时。/** 同步提交订单 */public static synchroni...

概括总结使用druid数据源之后，相对于第002版自己随手写的数据库，性能反而下降了8.49%。原因在于，002版是“随手”写的，因此功能非常简陋，要什么没什么，只能从内存中获取连接，因此很快。而druid数据源是一个工业级别的产品，它的内部做了大量的优化（比如多线程控制、性能监控等），这些优化的代码在运行的时候都是需要花时间的，因此相对就慢了一些。003版本更新说明pom.xml...

概括总结既然Java同步之后，性能这么差，那么有没有办法可以不使用Java同步呢？有的，那就是利用数据库修改的行数来验证库存。另外，假设现在库存是10，需要减少1，推荐的做法是update Goods set stock=stock-1，而不是update Goods set stock=9，后面的写法有同步的情况下性能差，在未同步的情况下直接是错的。011版本更新说明更新的思路是这样的...

概括总结这一版进一步减小了同步代码块，我以为会有相对明显一点的进步，但是结果并没有。010版本更新说明为了减小同步代码块，同时方便对比，拆分成了两个文件：Version010Method1.java、Version010Method2.java这个版本对比了以下两咱代码的性能：（代码为伪代码）第一种：同步代码块多一些public void submitOrder(省略参数) { ...