问题背景
本问题源于《ojdbc6中OraclePreparedStatement的ArrayIndexOutOfBoundsException异常BUG-6396242》这篇博文中最后思考的问题。
假如你的线上环境没有安装arthas，也无法追加–verbose:class或-XX:+TraceClassLoading然后重启，那么如何来定位具体class来自哪个jar包呢？
解决方法
使用中间件产品模块
-
WebSphere
Class Loader Viewer：Admin console -> Troubleshooting -> Class Loader Viewer
-
WebLogic
Classloader Analysis Tool (CAT)：
10.3.x 版本以后的版本Development模式中Deployments -> app_name -> Testing -> Classloader ->Analysis Tool.
但对于Production模式而言，则需要手动部署wls-cat.war，这种方式在线上环境意义不大。
使用Linux的lsof命令
lsof(List of Open Files)本质上是读取内存文件系统/proc/pid下的各种文件操作符，在一切皆文件的Linux世界没有lsof看不到的存在。
lsof –p <pid>
使用dump文件追踪相关的jar信息
使用jmap或者arthas拿到进程dump信息（线上环境要注意dump过程对机器的影响），然后jhat或者mat进行分析，这里为了方便使用mat。
首先查询出已知类的Classloader的所有实例，然后通过其成员寻找相关的加载路径和加载地址。
Tomcat
Tomcat几乎全部的jar都是由WebappClassLoader负责加载。
Weblogic
weblogic的AppClassLoader只加载了自定义domain里面的的相关jar，最终并没有涉及我们应用自身的/WEB-INF/lib下的jar
思考总结
-
应用运维角度
对于成熟的中间件产品来说应该使用专门的依赖库分析工具。 -
系统运维角度
利用lsof命令或者获取/proc/pid信息可以获取每个进程持有的相关资源当然包括打开的文件。 -
开发人员角度
通过jvm相关工具（jmap+jhat）可以拿到内存中任意class类的Classloader的实例以及其成员，当然这需要开发人员的配合或者运维人员具有一定的开发经验。
综合来看，三个角度中从开发角度考虑是最繁琐的。开发人员可以在开发测试阶段完全从代码层面跟踪具体问题，当然前提是测试发现了问题。
参考链接：
https://docs.oracle.com/cd/E24329_01/web.1211/e24368/classloading.htm#WLPRG495