JAVA的父类委托加载机制,再带来巨大便利性和效率提升的同时的同时也带来不少麻烦,最直接的就是类冲突造成的问题,以下场景不知道诸位是不是有点熟悉。
本文定义的类冲突定义为相同命名空间下的class分散在不通的jar包之中。
1、造成的注入系统混乱。
2、造成类型判断系统混乱,例如 if ((paramObject instanceof CLASSS))判断失灵
3、不同版本class实现方法有升级 例如Ajar包支持getXX(A,B),而另外jar中却只有getXX(A)
4、在数据在运算中的神秘失踪,如方法A jar中有方法void A(B b),C包中调用A的方法传入的对象 b和Ajar中的B加载的是有类冲突的B。运算结果可以想而知。
这种现象造成的一个问题就是程序员回说我的代码没有问题,我本地也是正常的....,之类的神奇现象,下面尝试去解决一下这几个问题。
1、个人认为首先要对类加载机制有个适当的了解。
以当前比较流行的tomcat为例:加载顺序个人认为讲的比较详细的查阅。
http://www.cnblogs.com/xing901022/p/4574961.html
http://www.ibm.com/developerworks/cn/java/j-lo-classloader/
2、定位一下我的classpath或者项目中会从那几个路径中加载,然后找出
我的程序到底加载的是哪个呢?
可以用该方法在文件中找出有哪些类有可能造成冲突。
代码语言:javascript复制import java.io.IOException;
import java.net.URL;
import java.net.URLDecoder;
import java.util.Enumeration;
import java.util.jar.JarEntry;
import java.util.jar.JarFile;
import java.io.*;
public class JarFinder {
public static void FindClassInJar(String jarName) throws IOException {
String filePath = jarName;
if (!filePath.endsWith(".jar")) {
代码语言:javascript复制 return;
代码语言:javascript复制} java.util.jar.JarFile file = new JarFile(filePath);
Enumeration<JarEntry> entrys = file.entries();
while (entrys.hasMoreElements()) {
JarEntry jar = entrys.nextElement();
String tmpJarName = jar.getName();
tmpJarName = tmpJarName.replace('/', '.');
if (tmpJarName.contains("javax.mail.Multipart")) {
System.out.println(tmpJarName " " file.getName());
}
}
file.close();
}
final static void ShowAllFileInDir(File dir) throws Exception {
File[] fs = dir.listFiles();for (int i = 0; i < fs.length; i ) {
String file = fs[i].getAbsolutePath();
FindClassInJar(file);
if (fs[i].isDirectory())
{try {
ShowAllFileInDir(fs[i]);
}
catch (Exception e) {
}
}
}
}
public static void main(String[] args) throws Exception {
File root = new File("C:/Program Files/Java/jdk1.8.0_102/jre/lib/ext");
ShowAllFileInDir(root);
}
}
3、减少相关jar包的数量
1、类统一,比如部署在tomcat上的不同项目每个项目多有jar A,那么不妨把jar A放在tomcat的/common/lib目录下。
2、尽量把能去掉的jar从项目中移除出去
此方法通常可以解决一大部分问题,个人认为也是解决这类问题的一个关键思路。
4、代码版本统一
解决问题的最好办法就是预防。部署在同一个tomcat下的项目使用的基础jar包要尽量统一,从制度和规范上解决这个问题。最好能一个公司统一的依赖库,maven是个不错的管理方式,公司按照统一的步调处理依赖项。
5、对于不能移除的可以通过控制jar包加载的顺序
6、确认不需要的jar包是否已经真从相关路径中移除。
个人就曾遇到从项目的依赖项中把jar去掉了,但是lib路径下仍存在这个jar导致的仍然被打到包里去了,活活郁闷两天。
其他有可能用到定位class路径的方法:
代码语言:javascript复制public static String getProjectPath() {
java.net.URL url = oracle.sql.NCLOB.class.getProtectionDomain().getCodeSource().getLocation();
String filePath = null;
try {
filePath = java.net.URLDecoder.decode(url.getPath(), "utf-8");
} catch (Exception e) {
e.printStackTrace();
}if (filePath.endsWith(".jar"))
filePath = filePath.substring(0, filePath.lastIndexOf("/") 1);
java.io.File file = new java.io.File(filePath);
filePath = file.getPath();
return filePath;
}
public static String getRealPath() {
String realPath = oracle.sql.NCLOB.class.getClassLoader().getResource("").getFile();//java.io.File file = new java.io.File(realPath);//realPath = file.(); System.out.println(realPath);try {
realPath = java.net.URLDecoder.decode(realPath, "utf-8");
} catch (Exception e) {
e.printStackTrace();
}
return realPath;
}
public static String getAppPath(Class<?> cls) {// 检查用户传入的参数是否为空
if (cls == null)throw new java.lang.IllegalArgumentException("参数不能为空!");
ClassLoader loader = cls.getClassLoader();// 获得类的全名,包括包名String clsName = cls.getName();// 此处简单判定是否是Java基础类库,防止用户传入JDK内置的类库
if (clsName.startsWith("java.") || clsName.startsWith("javax.")) {throw new java.lang.IllegalArgumentException("不要传送系统类!");
}// 将类的class文件全名改为路径形式String clsPath = clsName.replace(".", "/") ".class";
System.out.println(clsPath);
// 调用ClassLoader的getResource方法,传入包含路径信息的类文件名java.net.URL url = loader.getResource(clsPath);// 从URL对象中获取路径信息String realPath = url.getPath();
System.out.println(realPath);// 去掉路径信息中的协议名"file:"int pos = realPath.indexOf("file:");if (pos > -1) {
realPath = realPath.substring(pos 5);
}//System.out.println(realPath);// 去掉路径信息最后包含类文件信息的部分,得到类所在的路径//pos = realPath.indexOf(clsPath);//realPath = realPath.substring(0, pos - 1);// 如果类文件被打包到JAR等文件中时,去掉对应的JAR等打包文件名//if (realPath.endsWith("!")) {// realPath = realPath.substring(0, realPath.lastIndexOf("/"));//}//java.io.File file = new java.io.File(realPath);//realPath = file.getAbsolutePath();
try {
realPath = java.net.URLDecoder.decode(realPath, "utf-8");
} catch (Exception e) {throw new RuntimeException(e);
}return realPath;
}
从问题的两面性来看。这种加载机制也能给我带来便利性的一面。
比如我们要修改jar A中类B的实现,而我们又没有源代码,此时这种加载机制就很有用了。
我们只需要在项目的src中按照B的包名搭建即可。
不过使用此方法时要注意改类影响的范围,尽量不要在通用的类上执行此操作,否则会造成一些不可控的风险。