记录帖：碰到的一些Java问题
这个贴用于记录自己碰到过的一些Java问题，会根据经验不断增加，以便总结。:-)
CASE:
某Java Web API 程序，在进行LoadRunner压力测试时 200/user 发现8个CPU(4个双核)use 基本上都在 90%~100%之间了，http平均响应时间 2/s 左右，TPS极其低。
解决步骤：
既然CPU负载这么高，响应时间低，那么可以推测及有可能与 Java 线程有关系，于是通过 jstack -l [java pid]，发现有将近百多的 http 线程其 State 都处于 RUNNABLE，这不是问题，问题在于基本上所有的线程都在执行同一方法及同一代码行：
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.mapbar.logic.util.SocketUtil.getResponse(SocketUtil.java:63)
at com.mapbar.logic.geocoding.GeoCoding.getLonLat(GeoCoding.java:73)
"http-8068-51" daemon prio=10 tid=0x000000005ccbe000 nid=0x280c runnable [0x0000000045f5f000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at com.mapbar.logic.util.SocketUtil.getResponse(SocketUtil.java:63)
at com.mapbar.logic.geocoding.GeoCoding.getLonLat(GeoCoding.java:73)
于是可以断定代码 SocketUtil.getResponse 中的 Socket 调用几乎是肯定的罪魁祸首。
参考资料
Java Thread Dumps
An Introduction to Java Stack Traces
java.net.socketinputstream.socketread0 hangs thread
~~~~~
CASE:
因最近在使用 Hbase，但是 HBase 与 Hadoop 集成一直有一个问题，就是 之前的 Hadoop 0.20.x 版本一直不支持 append 操作，以至于HBase 下弄了一个 hadoop-core-0.20-append-r1056497.jar 的hadoop版本。不过后来hadoop发出了hadoop-0.20.205.0版本，而且已经拥有了 append 的支持。于是我便将该版本的hadoop与hbase-0.90.5进行整合，启动时一直提示：引用Caused by: java.lang.ClassNotFoundException: org.apache.commons.configuration.Configuration的异常，导致 HMaster 无法正常启动。
解决步骤：
1. 刪除 {hbase_home}/lib/hadoop-core-0.20-append-r1056497.jar
2. 將 {hadoop_home}/hadoop-core-0.20.205.0.jar复制到 {hbase_home}/lib/
3. 將 {hadoop_home}/commons-configuration-1.6.jar复制到 {hbase_home}/lib/
如果你的 hadoop_home 没有 commons-configuration-1.6.jar的话可以点这里下载。
重新启动 HBase 即可解决以上异常。 1 楼 cczakai 2011-11-28 怎么解决Socket存在的问题？
是Socket调用没有写好产生相互争抢资源，还是网络问题导致全部挂在这里？
2 楼 denger 2011-11-28 cczakai 写道怎么解决Socket存在的问题？
是Socket调用没有写好产生相互争抢资源，还是网络问题导致全部挂在这里？
我这边后续对 server 端进行了一些单独的测试，发现是由于server端高并发高时的其计算算法会导致 cpu 使用极高，以至于出现上面的 cpu 使用在 90%以上，才导致了其客户端 read 时间较长。
另外，其 server 端的代码是用C++实现，对C++不是很熟悉，已经交给其code author 处理优化了~
