本节以实际对比运行结果展示tbs的运行效率，模拟交易明细汇总，条件如下：
数据量：30w
计算逻辑：按账户号分组计算收入金额与支出金额，每500条记录汇总一次更新数据库。
硬件：4核3.3GHZ，16GB内存单机，Windows 7 专业版，4线程模拟4分片计算。
本节DEMO下载地址：点击下载
1、纯java实现计算结果如下：
17-12-26.15:51:56.039 [main ] INFO ClassPathXmlApplicationContext - Refreshing org.springframework.context.support.ClassPathXmlApplicationContext@1faccfb7: startup date [Tue Dec 26 15:51:56 CST 2017]; root of context hierarchy
17-12-26.15:51:56.087 [main ] INFO XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [application-context.xml]
17-12-26.15:51:56.442 [main ] INFO PropertyPlaceholderConfigurer - Loading properties file from file [F:\workspace\tbschedule_wed_demo\tbschedule-wed-standalone\target\classes\db.properties]
17-12-26.15:51:56.447 [main ] INFO AutowiredAnnotationBeanPostProcessor - JSR-330 'javax.inject.Inject' annotation found and supported for autowiring
分片：0 计算启动....
分片：1 计算启动....
分片：2 计算启动....
分片：3 计算启动....
分片：1 累计工作耗时：360437ms
分片：0 累计工作耗时：364454ms
分片：2 累计工作耗时：359437ms
分片：3 累计工作耗时：360880ms总计耗时：1445.208秒
2、tbs实现计算结果如下：
先解释上图配置以保证公平性：
a）任务采用处理休眠模式，但是休眠时间为0，模拟JAVA持续执行。
b）任务采用单机4线程组，4任务项，模拟JAVA单机4分片。
c）任务配置线程数为1，即单线程执行，模拟java也是单线程执行。
总计耗时：36.1970秒
3、xxl-job实现计算结果如下（待更新）：
| 工具 | CPU | 内存 | 成功率 | 耗时（单位：秒） |
| java | 25±1% | 80±10MB | 100% | 1445.208 |
| tbs | 25±1% | 120±10MB | 100% | 36.1970 |
| xxl-job | 25±1% | 120±20MB | 100% | 2190.613 |
备注：
a）在Win下，CPU占用没有参考意义。
b）因为测试机硬件有限，xxl-job被迫改为两分片执行。猜想4分片也差不了多少。
由此可见tbs之性能怪兽头衔名副其实，虽然目前版本对zookeeper的稳定性依赖较强，但得益于tbs将取数与计算形成抽象，隐藏内部优秀的线程状态管理。在单线程下性能尚且如此，试想一台16GB内存机器开启多线程性能得有多恐怖！
