v017-数据库ID为int(10)类型与long(20)类型的对比

第017版
int(10)类型的性能比long(20)类型的性能好4.01%（差别不明显）。
对应的博客在这里

v016-缓存商品

第016版
这一版测试把商品信息存在内存中，而不是每次都查询数据库。结果是：查询缓存比查询数据库的性能好5.28%。
对应的博客在这里

v015-收货地址由根据ID查询改为传参

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

v014-JDBC分别提交改为一起提交

第014版
提交订单时有3个对数据库有改动的操作，当3个操作一起提交时，比3个操作分别提交的性能要高8.40%。
对应的博客在这里

v013-测试SQL语句中少查询几个字段(包括大字段)

第013版
这一版本写了两个测试类，一个测试类中查询全部字段，另一个测试类中只查询必要的字段，然后对比性能。结论是：根据是减少的字段的长度不同，性能会不同。具体请查看下面的测试结果。
对应的博客在这里

v012-引入FutureTask

第012版
引入FutureTask能提高并发度，相应就可以提升性能，这次测试的结是，提升了38.93%（参考值）。它的缺点也很明显，就是增加了代码的复杂度，不方便阅读了，且对异常也要额外处理，而且大家对FutureTask也不是很熟悉。衡量利弊之后，我觉得是值得引入的。
对应的博客在这里

v011-放弃java同步，引入数据库修改行数来验证库存

第011版
这一版放弃了java同步，引入数据库修改行数来验证库存，性能提升一个数量级。
对应的博客在这里

v010-进一步减小同步代码块（中的非关键代码）

第010版
这一版进一步减小了同步代码块（中的非关键代码），我以为会有相对明显一点的进步，但是结果并没有。
对应的博客在这里

v009-对比整个方法同步与方法中的部分代码同步

第009版
在用到synchronized关键字的时候，凭直觉就会加在方法上，比如public static synchronized void test(){}，但是这种直觉不见得是对的，估计大部分时候是出图方便，想偷懒，才直接加到方法上的。推荐的做法是：仅仅只同步需要同步的代码。
对应的博客在这里

v008-对比static方法与非static方法

第008版
在这个版本中，把提交订单的方法设置成public static synchronized的，与仅仅是设置public synchronized的，在提交订单的性能上有什么差别？答案是：没有明显区别（是同样的差）。
对应的博客在这里