AMD 双核 2.8G ,4G内存 winxp

java+concjava+AKKA1.3java+AKKA2.0Scala+AKKA1.3Scala+AKKA2.0Go+goroutine

1-N

单位：秒

10000000.641.140.631.050.650.617

20000001.712.081.582.051.681.63

30000003.053.282.793.32.962.91

50000006.326.185.756.3676.16.04

10000000       17.1415.8515.816.516.616.35

12000000        22.420.48          20.221.3221.4821.3

(由于AMD硬件平台性能很烂，测试时间较长，所以只测试到12000000)

INETL 平台 酷睿双核2.4G ,4G内存 winxp

java+concurrentjava+AKKA1.3java+AKKA2.0Scala+ AKKA1.3Scala+ AKKA2.0Go+goroutine

1-N单位：秒

10000000.2090.870.2350.730.2190.28

20000000.531.120.480.980.4850.54

50000001.932.191.552.081.611.65

100000004.934.624.094.574.14.18

2000000013.2511.1410.9511.1310.9210.98

3000000023.2419.3719.1319.2519.3519.39

测试真是又费时间又枯燥的事情。在两个硬件平台测试了之后，还有一个苹果系统的没有时间进行测试，先放着，等以后再补上吧。

性能测试结果说明：

1、为了公平起见，各个组合的算法都是采用给多线程传递不变的参数，避免使用同步锁，尽量减少因为实现语言的不同而影响性能的因素。

2、性能表现最好的前3个分别是：java+AKKA2.0，Scala+AKKA2.0，Go+goroutine。这3个组合的多线程并发计算指标比较接近。尽管在测试前，对Go语言报了很大期望，以为Go会是测试的冠军，但事实证明，对这个CPU密集运算的多线程并发测试案例来说，Go并不占优势，甚至不如java+AKKA2.0组合。这也证明了AKKA这个高性能并发运算框架果然很优异。不了解AKKA2.0的朋友，请访问：http://www.gtan.com/akka_doc/index.html。

3、性能表现最常的是java+concurrent。当计算量小的时候，例如，1000000以下的时候，java+concurrent表现还不错。但计算量不断增大的时候，java+concurrent开始表现糟糕。在10000000以上的时候，java+concurrent表现更加糟糕。表现糟糕的原因可能是因为用到了 concurrent

的ExecutorService和Future。 Future其实是一种阻塞线程模式，所以性能并不是最佳。有时间读读AKKA2.0的源代码，也许能找到一些改进性能的参考办法。

4、性能表现一般的是java+AKKA1.3和Scala+AKKA1.3。它们和AKKA2.0版本的最大差异是，它们采用的是发送并等待返回消息的阻塞模式，而AKKA2.0版本则采用发送就不管了的无阻塞模式。事实证明，阻塞模式比无阻塞模式性能要差不少。此外，尽管AKKA1.3的阻塞模式性能不好，但在大计算量的情况下表现仍然不错，和Go语言差不多，比java+concurrent要好。

5、在运行java程序的时候，都加上了-server参数。而对于Scala和Go，我不了解该怎么优化，所以都只是使用Scala和Go普通的运行命令来启动程序。例如，

java -server org.aos.concurrent.samples.ConcurrentPrimeFinder 1000000 10 100

scala com.agiledeveloper.pcj.Primes 1000000 100

test_prime.exe -n=1000000 -workers=100

编程的难易程度测试结果说明：

1、由于本人有多年的JAVA编程经验，所以java+concurrent组合是编码花费时间最少的。

2、对于Scala和Go语言，本人学习的时间都差不多，3个星期左右。由于Scala和JAVA平台的互通性，也由于Scala平台的成熟和易用(开发工具和语法比Go好不少)，所以开发Scala版本比Go版本所花费的时间要少。

3、Scala+AKKA1.3比Scala+AKKA2.0版本更容易开发。因为Scala+AKKA1.3的阻塞模式容易理解，代码量也少。但阻塞模式在计算量比较大的时候，容易报timeout异常。需要增加一个akka.conf文件来定义更长的阻塞等待时间。对于Scala+AKKA2.0，AKKA官方提供了一个无阻塞模式的参考例子，采用master+worker+listener对象组合。Master分发多份工作给多个worker去计算,

worker计算完后，分别把各自计算结果发回给master来汇总，最终，master把汇总结果发送给listener，并输出结果。为了使用这种对象组合，导致Scala+AKKA2.0版本的编码要比Scala+AKKA1.3版本复杂，花费的时间也相应要多些。另外，由于AKKA2.0采用无阻塞的模式，所以测试中没有出现过由于计算量大而出现的timeout问题。

4、从Scala转到Java版本，确实有些困难，但幸好两个平台是互通的，并且有参考的例子，所以转过来也不是太困难。和Scala版本一样的，java+AKKA1.3版本比java+AKKA2.0版本要容易写些，也存在着阻塞模式的timeout问题。

5、Go语言版本，由于和Java平台不互通，而且差异极大，编码花费时间最多。Go语言从Scala和Python等语言里获取了许多有益的东西，语法比较简洁，编译速度快，占用内存少，而且以goroutine的方式很方便地写出支持多线程并发计算的程序，确实很有发展前景。(在用过Scala和Go语言之后，真的很讨厌JAVA里面冗长的代码，特别是该死的分号‘;’)

但Go语言的缺陷也挺多的。这里就列几个测试所发现的情况：1)语言比较新，懂的人不多。这意味着学习成本和用人成本比较高；2)开发平台不成熟，在windows下安装配置Go的开发环境，本人的经历很痛苦。有一种当年用EditPlus写JAVA代码的感觉，很不爽。3)强类型转换，很烦人。为了使用math.Sqrt，居然逼我写了一段从float64转int的代码。在Java和Scala从未出现这样的情况。算是明白了，Go所谓的编译快其实就是程序员自己多付出点代价来照看代码。4)goroutine容易出现deadlock死锁现象。死锁的原因很多，让初学者头痛。

测试的最终结论：

综合性能测试和编码难易程度测试结果，本人从做项目的角度得出几点结论:

1、对于Java程序员，如果没有强制性的必要，不需要转到Scala和Go语言，因为Java+AKKA2.0足够好用了，足以应付多线程高并发应用。

2、对于Java程序员，如果程序应用于一般的多线程应用，并且性能要求不高，java的concurrent包也够用了。

3、对于Java程序员，如果想让项目的代码量减少一半，学习成本不太高，性能也有保障的话，Scala语言是非常好的选择。

4、对于Java程序员，如果项目时间有限，想要用Go语言来实现项目，那基本死路一条。

5、对于Go语言的未来，也许如Go编程语言QQ群里的朋友所说的那样，在云计算领域可能会大放光彩。

由于能力、精力和资源有限，这次比较测试并不完美，可能存在不少问题。欢迎有兴趣的朋友讨论并发表意见。

有疑问加站长微信联系(非本文作者)