以下分享几种java言语经常运用的通信协定及协定机能的比较
1.RMI
RMI挪用与想象的一样，RMI天经地义是最快的，在险些一切的状况下，它的毫时都是起码的。迥殊是在数据结构庞杂，数据量大的状况下，与其他协定的差异尤其显著。为了充分发挥RMI的机能，别的做了测试类，不运用Spring，用原始的RMI情势（继续UnicastRemoteObject对象）供应效劳并长途挪用，与Spring对POJO包装成的RMI举行效力比较。效果显现：二者基础持平，Spring供应的效劳还稍快些。开端以为，这是由于Spring的代办和缓存机制比较壮大，节省了对象从新猎取的时候。
2.Hessian
Hessian挪用caucho公司的resin效劳器号称是最快的效劳器，在java范畴有肯定的知名度。Hessian做为resin的组成部分，其设想也非常精简高效，现实运转状况也证清楚明了这一点。均匀来看，Hessian较RMI要慢20%摆布，但这只是在数据量迥殊大，数据结构很庞杂的状况下才表现出来，中等或少许数据时，Hessian并不比RMI慢。Hessian的优点是精简高效，能够跨言语运用，而且协定范例公然，我们能够针对恣意言语开辟对其协定的完成。现在已有完成的言语有：java, c++, .net, python, ruby。还没有delphi的完成。别的，Hessian与WEB效劳器连系非常好，借助WEB效劳器的功用，在处置惩罚大批用户并发接见时会有很大上风，在资本分派，线程列队，非常处置惩罚等方面都能够由成熟的WEB效劳器保证。而RMI自身并不供应多线程的效劳器。而且，RMI须要开防火墙端口，Hessian不必。
3.Burlap
Burlap与Hessian都是caucho公司的开源产物，只不过Hessian采纳二进制的体式格局，而Burlap采纳xml的花样。测试效果显现，Burlap在数据结构不庞杂，数据量中等的状况下，效力照样能够接收的，但假如数据量大，效力会急剧下降。均匀盘算，Burlap的挪用毫时是RMI的3倍。我以为，其效力低有两方面的缘由，一个是XML数据形貌内容太多，一样的数据结构，其传输量要大许多；另一方面，尽人皆知，对xml的剖析是比较费资本的，迥殊关于大数据量状况下更是如此。
4.HttpInvoker
HttpInvoker是SpringFramework供应的JAVA长途挪用要领，运用java的序列化机制处置惩罚对象的传输。从测试效果看，其效力照样能够的，与RMI基础持平。不过，它只能用于JAVA言语之间的通信，而且，要求客户端和效劳端都运用SPRING框架。别的，HttpInvoker 并没有经由实践的磨练，现在还没有找到运用该协定的项目。
5.web service
本次测试选用了apache的AXIS组件作为WEB SERVICE的完成，AXIS在WEB SERVICE范畴相对成熟老牌。为了仅测试数据传输和编码、解码的时候，客户端和效劳端都运用了缓存，对象只需实例化一次。然则，测试效果显现，web service的效力照样要比其他通信协定慢10倍。假如考虑到多个援用指向统一对象的传输状况，web service要落伍更多。由于RMI，Hessian等协定都能够通报援用，而web service有若干个援用，就要复制若干份对象实体。Web service传输的冗余信息过多是其速度慢的缘由之一，监控发明，一样的接见要求，形貌雷同的数据，web service返回的数据量是hessian协定的6.5倍。别的，WEB SERVICE的处置惩罚也很毫时，现在的xml剖析器效力广泛不高，处置惩罚xml <-> bean很毫资本。从测试效果看，异地挪用比当地挪用要快，也从正面说清楚明了其毫时重要用在编码和解码xml文件上。这比冗余信息更为严重，冗余信息占用的只是网络带宽，而每次挪用的资本消耗直接影响到效劳器的负载才能。（MS的工程师曾说过，用WEB SERVICE不能负载100个以上的并发用户。）测试过程当中还发明，web service编码不甚轻易，对非基础范例须要逐一注册序列化和反序列化类，很贫苦，生成stub更累，不如spring + RMI/hessian处置惩罚那末流通简约。而且，web service不支撑鸠合范例，只能用数组，不轻易。
以上就是java言语支撑什么协定的细致内容，更多请关注ki4网别的相干文章！
