Sky's blog

我和我追逐的梦

常用链接

统计

其他链接

友情链接

最新评论

sun的程序员也是程序员啊!


    依然是近期工作中发现的问题,真实案例,写下来分享给大家。

    在开始本文之前,援引同事对此案例的一句评语:sun的程序员也是程序员啊!

    开始讲故事吧,依然是performance tuning,还是老伎俩,加压力,做thread dump,然后检查。结果就发现有如下的线程,而且比率极大:dump出来大概总共70-80个工作线程,有5-6个在做这个事情,还有大概50个在等着做这个事情,也就是说大概80%+的工作线程都于此有关。

"HTTPBC-OutboundReceiver-221" daemon prio=3 tid=0x09872c00 nid=0x4bf9 runnable [0xa7b56000]
   java.lang.Thread.State: RUNNABLE
    at java.util.zip.ZipFile.getEntry(Native Method)
    at java.util.zip.ZipFile.getEntry(ZipFile.java:
149)
    
- locked <0xbb09d458> (a java.util.jar.JarFile)
    at java.util.jar.JarFile.getEntry(JarFile.java:
206)
    at java.util.jar.JarFile.getJarEntry(JarFile.java:
189)
    at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:
754)
    at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:
732)
    at sun.misc.URLClassPath$
1.next(URLClassPath.java:195)
    at sun.misc.URLClassPath$
1.hasMoreElements(URLClassPath.java:205)
    at java.net.URLClassLoader$
3$1.run(URLClassLoader.java:393)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.net.URLClassLoader$
3.next(URLClassLoader.java:390)
    at java.net.URLClassLoader$
3.hasMoreElements(URLClassLoader.java:415)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:
27)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:
36)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:
27)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:
36)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:
27)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:
36)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:
27)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:
36)
    at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:
27)
    at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:
36)
    at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:
357)
    at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:
129)
    at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:
112)
    at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:
595)
    at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:
554)
    at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:
539)
    at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:
436)
    
- locked <0xe8e3e200> (a com.sun.xml.ws.api.pipe.Fiber)
    at com.sun.xml.ws.api.pipe.helper.AbstractTubeImpl.process(AbstractTubeImpl.java:
106)
    at com.sun.xml.ws.tx.client.TxClientPipe.process(TxClientPipe.java:
177)
    at com.sun.xml.ws.api.pipe.helper.PipeAdapter.processRequest(PipeAdapter.java:
115)
    at com.sun.xml.ws.api.pipe.Fiber.__doRun(Fiber.java:
595)
    at com.sun.xml.ws.api.pipe.Fiber._doRun(Fiber.java:
554)
    at com.sun.xml.ws.api.pipe.Fiber.doRun(Fiber.java:
539)
    at com.sun.xml.ws.api.pipe.Fiber.runSync(Fiber.java:
436)
    
- locked <0xe8e3e200> (a com.sun.xml.ws.api.pipe.Fiber)
    at com.sun.xml.ws.client.Stub.process(Stub.java:
248)
    at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:
180)
    at com.sun.xml.ws.client.dispatch.DispatchImpl.invoke(DispatchImpl.java:
206)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.outboundCall(OutboundMessageProcessor.java:
1256)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.dispatch(OutboundMessageProcessor.java:
1296)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processRequestReplyOutbound(OutboundMessageProcessor.java:
747)
    at com.sun.jbi.httpsoapbc.OutboundMessageProcessor.processMessage(OutboundMessageProcessor.java:
257)
    at com.sun.jbi.httpsoapbc.OutboundAction.run(OutboundAction.java:
63)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:
886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:
908)
    at java.lang.Thread.run(Thread.java:
619)


    忘了介绍一下背景:openESB运行于 glassfish平台,一个bepl 调用4个webservice.上面的线程HTTPBC-OutboundReceiver 是openESB中作为客户端调用webservice的工作线程,从调用栈中可以看到:
1. task被executor执行
2. jbi中的httpsoapbc用来处理消息
3. com.sun.xml.ws.client使用Stub来处理信息,标准的webservice调用
4. 最重要的两行,我们后面再来看这里发生了什么
    at com.sun.xml.ws.api.pipe.TransportTubeFactory.create(TransportTubeFactory.java:129)
    at com.sun.xml.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:112)
5. ServiceFinder,通过Iterator.hasNext在做游历
6. java的classloader在find resource
7. 为了从jar包中装载resouce,需要处理解压缩,java.util.zip被调用

    OK,现在整体看,在处理webservice的调用过程中,需要在classpath路径下载入资源,而且看样子这个资源的载入还是很耗cpu时间的。

    先看看在装载什么资源,上面的调用明显是jax-ws,glassfish下跑的是metro的实现。在glassfish目录下找到webservice-rt.jar,打开看META-INF/MANIFEST.MF,找到Name: jaxws-rt.jar这段,发现有Implementation-Version: 2.1.3.1,上metro的官网,找metor 相应版本的源文件,最接近的是2.1.3。下载下来查看源码,恩,开源就是好啊。

    首先找到ServiceFinder类,代码片段:

com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:357)
private static  final String  prefix = "META-INF/services/";
 
if (configs  == null) {
                    String fullName 
= prefix + service.getName();
                    
if (loader == null)
                        configs 
= ClassLoader.getSystemResources(fullName);
                    
else
                        configs 
= loader.getResources(fullName);
}

    非常通用的做法,META-INF/services/下查找资源看改用哪个实现。

    逆推找到类TransportTubeFactory中对此的调用代码:

    public static Tube create(@Nullable ClassLoader classLoader, @NotNull ClientTubeAssemblerContext context) {
        
for (TransportTubeFactory factory : ServiceFinder.find(TransportTubeFactory.class,classLoader)) {
            Tube tube 
= factory.doCreate(context);
            
if(tube !=null) {
                TransportTubeFactory.logger.fine(factory.getClass()
+" successfully created "+tube);
                
return tube;
            }
        }

    代码的意图很明显,create()方法在classpath下找到TransportTubeFactory的实现,然后逐个尝试创建Tube对象。

    疑问就来了,为什么每次请求都要create, 这里的create明显是重量级的,需要到classpath下去查找一下某个Factory的实现。明显不合理,继续逆推代码,在类DeferredTransportPipe中找到对create的调用:

    public NextAction processRequest(@NotNull Packet request) {
        
if(request.endpointAddress==address)
            
// cache hit
            
return transport.processRequest(request);
    .....
        address 
= request.endpointAddress;
        transport 
= TransportTubeFactory.create(classLoader, newContext);

    不出意料的,这里有cache: 如果endpoint address和上次相同,直接重用,否则就调用create方法。从前面的现象看,cache没有命中,至少没有全部命中。

    由于我们的测试的案例是连续调用4个不同的webservice,当然每个webservice的endpoint address是不同的。因此第一反应是这里transport cache机制被四个webservice的client端公用,因此每次调用只有1/4的概率和上次相同,其他的3/4就只能重新创建。之后花费了大量时间和精力去查看openesb的代码,过程不提,结果就是无果。

    再回头来看这个cache的地方,有点奇怪为什么不命中。好在可以做remote debug,debug进入,到if(request.endpointAddress==address ) 这行,发现果然没有命中,但是随即检查request.endpointAddress和 address的值,非常惊讶的发现里面的实际值是相同的!!

    直接晕倒!

if(request.endpointAddress==address )

    值相同而==不成立,那么就是说这里的request.endpointAddress 和 address 并不是一般的enum或者类型安全枚举, ==的检测根本不成立。

    这是sun的代码啊,sun的程序员也会犯这种低级错误?用 == 来比较普通对象而不是用equals()方法?

    继续看EndpointAddress 这个类,无语了:

1. 这是个普通的类,根本不是enum或者类型安全枚举,有两个publish的构造函数,理论上,使用者可以随意创建任意数量的实例
2. 没有重载equals方法,因此即使改用equals方法来提到==的检查也是无意义的,默认的equals()还是检查对象引用

    因此,再来看DeferredTransportPipe中的这段试图重用cache的代码

    public NextAction processRequest(@NotNull Packet request) {
        
if(request.endpointAddress==address)
            
// cache hit
            
return transport.processRequest(request);

    这里的"if(request.endpointAddress==address)"能否成立,完全取决于客户端的调用方法:如果调用方保证每次相同endpointAddress的请求,request.endpointAddress都会是同一个实例,则这里的cache可以命中。否则这个cache毫无意义,还是需要每次重新创建重量级的transport对象。我们的测试案例中,很明显,openESB的程序员,没有考虑到DeferredTransportPipe这里的"特殊"要求,每次调用传入的request.endpointAddress虽然里面的实际值相同,但是每次都是不同的实例。因此 == 不成立,cache不命中。

    查找了一下相关的类和接口定义,对于方法public NextAction processRequest(Packet request) 和 Packet中的endpointAddress属性,没有任何javadoc说明要求Packet中的endpointAddress属性需要做到相同地址只使用一个对象实例。

    看Packet中的endpointAddress的设值代码:

   public void setEndPointAddressString(String s) {
        
if(s==null)
            
this.endpointAddress = null;
        
else
            
this.endpointAddress = EndpointAddress.create(s);
    }
    
public static EndpointAddress create(String url) {
        
try {
            
return new EndpointAddress(url);
        } 
catch(URISyntaxException e) {
            
throw new WebServiceException("Illegal endpoint address: "+url,e);
        }
    }

    明显每次通过调用setEndPointAddressString()设置时都会产生一个新的EndpointAddress实例。看代码时还意外的发现,

    public EndpointAddress endpointAddress;

    这个endpointAddress属性居然是public的!! 看样子,DeferredTransportPipe类的开发者,是寄希望于调用者不要通过Packet.setEndPointAddressString(String s)来设置,而是希望直接使用public的属性,这样才有希望命中cache!这分明是在挖坑,而且明显现在openESB的开发者被坑进去了!

    鄙视啊鄙视,这样的代码,居然是sun的程序员写出来的,还放在metro里面,而metro作为默认的jax-ws实现被放在jdk中...... 很是无语。

    无奈之下,修改代码,将 == 去掉,自己简单的判断一下endpointAddress的实际值

        if (address != null
                
&& address.getURI() != null
                
&& request.endpointAddress.getURI().equals(address.getURI())) {
            
// cache hit
            return transport.processRequest(request);
        }

    将编译出来的class文件,替换glassfish/lib/webservice-rt.jar中的相同文件,重新测试。再次thread dump,发现问题解决了。

    期间看了一下DeferredTransportPipe类的各个version的代码,这里的 == 一直都没有改,难道sun就一直没有发现这里有问题?有兴趣的可以通过下面的地址使用fisheye来查看这个类的代码:

http://fisheye5.cenqua.com/browse/jax-ws-sources/jaxws-ri/rt/src/com/sun/xml/ws/transport/DeferredTransportPipe.java?r1=1.3&r2=1.3.4.1&u=-1


    总结:用 == 来比较非enum或者类型安全枚举的对象实例,这种错误一般只有初学者才犯,万万没有想到,能在metro这样级别的代码中也能出现。无限感叹啊,再次援引同事的评语作为本文的结束语:

    sun的程序员也是程序员啊!

后续更新:

1. 做了这个bug解决前后的性能对比,相同机器相同环境

fix前: CPU: 89%-92%   TPS:1111   AVG response time:71

fix后: CPU: 69%-71%   TPS:1300   AVG response time:61  

总结说就是fix之后,tps 提升接近20%,而cpu使用反而降低20%,平均响应时间减少14%。

反过来,看原来的这个bug对性能的影响有多大,如此差异仅仅源于一行代码而已。

2. 提交给sun的tr,24小时了,没有任何反应

https://jax-ws.dev.java.net/issues/show_bug.cgi?id=854

    好吧,不能指望sun了。


posted on 2010-05-05 16:48 sky ao 阅读(2629) 评论(3)  编辑  收藏 所属分类: 杂谈

评论

# re: sun的程序员也是程序员啊! 2010-05-05 17:52 滴水

看起来人家就是要比较引用,被lz误解了。  回复  更多评论   

# re: sun的程序员也是程序员啊! 2010-05-05 18:12 sky ao

如果比较引用的话,那么它的cache基本就没有办法实现,除非上面调用的人帮它特殊处理。

至少openESB的开发人员没有理解到这点,呵呵,所以出现每次请求都重新create的问题。  回复  更多评论   

# re: sun的程序员也是程序员啊! 2013-07-17 09:27 dohkoos

lz完全理解错了,把开发应用的思想放到了开发组件上。

在组件中你只能用==比较地址,因为你不知道传进来的对象里有哪些字段是需要比较的。Object的equals方法就是最好的例子。  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航: