提交订单性能优化系列之010-进一步减小同步代码块（中的非关键代码）

---

概括总结

这一版进一步减小了同步代码块，我以为会有相对明显一点的进步，但是结果并没有。

---

010版本更新说明

为了减小同步代码块，同时方便对比，拆分成了两个文件：Version010Method1.java、Version010Method2.java

这个版本对比了以下两咱代码的性能：（代码为伪代码）

第一种：同步代码块多一些

public void submitOrder(省略参数) {
  // 1、查询用户
  // 3、查询地址
  synchronized (this) {
    // 2、查询商品
    // 4、检查全部相关的参数是否正确
    // 7、更新商品的库存与销量
  }
  // 5、保存订单到数据库中，并返回订单ID
  // 6、保存订单商品到数据库中
}

第二种：同步代码块少一些

public void submitOrder(省略参数) {
  synchronized (this) {
    // 2、查询商品
    // 4、检查商品相关的参数是否正确
    // 7、更新商品的库存与销量
  }
  // 1、查询用户
  // 3、查询地址
  // 8、检查其他参数
  // 5、保存订单到数据库中，并返回订单ID
  // 6、保存订单商品到数据库中
}

第一种：从数据库查出用户、从数据库查出地址、从数据库查出商品、在同步代码块中同时检查这三个参数是否正确

第二种：先不从数据库查出用户、也不从数据库查出地址、只从数据库查出商品、在同步代码块中只检查商品相关的代码是否正确

因此，第二种少了两步从数据库查询的操作，同时检查的参数也少了一些，总体来说，即同步代码块少一些。

---

测试结果

统计10次测试的平均值之后：

同步代码块多一些，每秒钟可以提交的订单数为：14

同步代码块少一些，每秒钟可以提交的订单数为：14

同步代码块多一些，提交每个订单平均耗时的纳秒数：65733853

同步代码块少一些，提交每个订单平均耗时的纳秒数：65896851

性能差别为：(65896851 - 65733853) / 65733853 * 100% = 0.24%，即第二种方法比第一种方法的性能下降了0.24%，没有明显差异

【备注】：不同的机器上的测试结果会不一样，以上测试结果仅供参考。

---

测试结果说明

那么问题来了：同步代码块明明少了，减少了两次查询数据库的机会呀，怎么会没有性能提升呢？

答案是：减少的那两次查询没有在同步代码中，是并发访问的，对整体时间的影响不大。

另外值得一提的是，这次发现测试代码的顺序对测试结果有影响。举例来说：

测试顺序1：

初始化数据库（销毁数据库、然后新建数据库）
测试`同步代码块多一些`的代码
关闭所有数据库连接

初始化数据库（销毁数据库、然后新建数据库）
测试`同步代码块少一些`的代码
关闭所有数据库连接

测试顺序2：

初始化数据库（销毁数据库、然后新建数据库）
测试`同步代码块少一些`的代码
关闭所有数据库连接

初始化数据库（销毁数据库、然后新建数据库）
测试`同步代码块多一些`的代码
关闭所有数据库连接

统计10次测试的平均值之后：

同步代码块少一些，提交每个订单平均耗时的纳秒数：65388623

同步代码块多一些，提交每个订单平均耗时的纳秒数：66342731

性能差别为：(66342731 - 65388623) / 65388623 * 100% = 1.45%，同步代码少一些的性能比同步代码多一些好一点，但是差异也不算明显。

至于为什么测试的顺序能影响测试的结果，我还没有找到原因。不过好在影响不算大，而实际项目中，100个Service，1000个方法，想控制顺序几乎是不可能的，所以我们以后就不再考虑测试的顺序了。

---

源码

010版本的github源码在这里，如果不知道怎样运行项目，请参考这里