javaclassloader加密
‘壹’ 为什么要自定义classloader
比较典型的自定义classloader使用情况就是给类加密。java编译的代码可以轻易的被反编译，有些企业会给自己的类做特殊的加密，防止反编译，类加密后就不能再用java的
classloader去加载类了，这时就需要自定义classloader，再加载类的时候先解密类，然后再加载。
具体的代码自己可以网络一下class加密有很多文章介绍的。
‘贰’ classloader来自哪个类
ClassLoader主要对类的请求提供服务，当JVM需要某类时，它根据名称向ClassLoader要求这个类，然后由ClassLoader返回这个类的class对象。 1.1 几个相关概念ClassLoader负责载入系统的所有Resources（Class，文件，来自网络的字节流等），通过ClassLoader从而将资源载入JVM
每个class都有一个reference，指向自己的ClassLoader。Class.getClassLoader()
array的ClassLoader就是其元素的ClassLoader，若是基本数据类型，则这个array没有ClassLoader
1.2 主要方法和工作过程Java1.1及从前版本中，ClassLoader主要方法：
Class loadClass( String name, boolean resolve ); ClassLoader.loadClass() 是 ClassLoader 的入口点
defineClass 方法是 ClassLoader 的主要诀窍。该方法接受由原始字节组成的数组并把它转换成 Class 对象。原始数组包含如从文件系统或网络装入的数据。
findSystemClass 方法从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用 defineClass 将原始字节转换成 Class 对象，以将该文件转换成类。当运行 Java 应用程序时，这是 JVM 正常装入类的缺省机制。
resolveClass可以不完全地（不带解析）装入类，也可以完全地（带解析）装入类。当编写我们自己的 loadClass 时，可以调用 resolveClass，这取决于 loadClass 的 resolve 参数的值
findLoadedClass 充当一个缓存：当请求 loadClass 装入类时，它调用该方法来查看 ClassLoader 是否已装入这个类，这样可以避免重新装入已存在类所造成的麻烦。应首先调用该方法
一般load方法过程如下：
调用 findLoadedClass 来查看是否存在已装入的类。
如果没有，那么采用某种特殊的神奇方式来获取原始字节。（通过IO从文件系统，来自网络的字节流等）
如果已有原始字节，调用 defineClass 将它们转换成 Class 对象。
如果没有原始字节，然后调用 findSystemClass 查看是否从本地文件系统获取类。
如果 resolve 参数是 true，那么调用 resolveClass 解析 Class 对象。
如果还没有类，返回 ClassNotFoundException。
否则，将类返回给调用程序。
1.3 委托模型自从JDK1.2以后，ClassLoader做了改进，使用了委托模型，所有系统中的ClassLoader组成一棵树，ClassLoader在载入类库时先让Parent寻找，Parent找不到才自己找。
JVM在运行时会产生三个ClassLoader，Bootstrap ClassLoader、Extension ClassLoader和App ClassLoader。其中，Bootstrap ClassLoader是用C++编写的，在Java中看不到它，是null。它用来加载核心类库，就是在lib下的类库，Extension ClassLoader加载lib/ext下的类库，App ClassLoader加载Classpath里的类库，三者的关系为:App ClassLoader的Parent是Extension ClassLoader，而Extension ClassLoader的Parent为Bootstrap ClassLoader。加载一个类时，首先BootStrap进行寻找，找不到再由Extension ClassLoader寻找，最后才是App ClassLoader。
将ClassLoader设计成委托模型的一个重要原因是出于安全考虑，比如在Applet中，如果编写了一个java.lang.String类并具有破坏性。假如不采用这种委托机制，就会将这个具有破坏性的String加载到了用户机器上，导致破坏用户安全。但采用这种委托机制则不会出现这种情况。因为要加载java.lang.String类时，系统最终会由Bootstrap进行加载，这个具有破坏性的String永远没有机会加载。
委托模型还带来了一些问题，在某些情况下会产生混淆，如下是Tomcat的ClassLoader结构图:
Bootstrap
|
System
|
Common
/
Catalina Shared
/
Webapp1 Webapp2 ...
由 Common 类装入器装入的类决不能（根据名称）直接访问由 Web 应用程序装入的类。使这些类联系在一起的唯一方法是通过使用这两个类集都可见的接口。在这个例子中，就是包含由 Java servlet 实现的 javax.servlet.Servlet。
如果在lib或者lib/ext等类库有与应用中同样的类，那么应用中的类将无法被载入。通常在jdk新版本出现有类库移动时会出现问题，例如最初我们使用自己的xml解析器，而在jdk1.4中xml解析器变成标准类库，load的优先级也高于我们自己的xml解析器，我们自己的xml解析器永远无法找到，将可能导致我们的应用无法运行。
相同的类，不同的ClassLoader，将导致ClassCastException异常
1.4 线程中的ClassLoader每个运行中的线程都有一个成员contextClassLoader，用来在运行时动态地载入其它类，可以使用方法Thread.currentThread().setContextClassLoader(...);更改当前线程的contextClassLoader，来改变其载入类的行为；也可以通过方法Thread.currentThread().getContextClassLoader()来获得当前线程的ClassLoader。
实际上，在Java应用中所有程序都运行在线程里，如果在程序中没有手工设置过ClassLoader，对于一般的java类如下两种方法获得的ClassLoader通常都是同一个
this.getClass.getClassLoader()；
Thread.currentThread().getContextClassLoader()；
方法一得到的Classloader是静态的，表明类的载入者是谁；方法二得到的Classloader是动态的，谁执行（某个线程），就是那个执行者的Classloader。对于单例模式的类，静态类等，载入一次后，这个实例会被很多程序（线程）调用，对于这些类，载入的Classloader和执行线程的Classloader通常都不同。
1.5 Web应用中的ClassLoader回到上面的例子，在Tomcat里，WebApp的ClassLoader的工作原理有点不同，它先试图自己载入类（在ContextPath/WEB-INF/...中载入类），如果无法载入，再请求父ClassLoader完成。
由此可得：
对于WEB APP线程，它的contextClassLoader是WebAppClassLoader
对于Tomcat Server线程，它的contextClassLoader是CatalinaClassLoader
1.6 获得ClassLoader的几种方法可以通过如下3种方法得到ClassLoader
this.getClass.getClassLoader(); // 使用当前类的ClassLoader
Thread.currentThread().getContextClassLoader(); // 使用当前线程的ClassLoader
ClassLoader.getSystemClassLoader(); // 使用系统ClassLoader，即系统的入口点所使用的ClassLoader。（注意，system ClassLoader与根ClassLoader并不一样。JVM下system ClassLoader通常为App ClassLoader）
1.7 几种扩展应用用户定制自己的ClassLoader可以实现以下的一些应用
安全性。类进入JVM之前先经过ClassLoader，所以可以在这边检查是否有正确的数字签名等
加密。java字节码很容易被反编译，通过定制ClassLoader使得字节码先加密防止别人下载后反编译，这里的ClassLoader相当于一个动态的解码器
归档。可能为了节省网络资源，对自己的代码做一些特殊的归档，然后用定制的ClassLoader来解档
自展开程序。把java应用程序编译成单个可执行类文件，这个文件包含压缩的和加密的类文件数据，同时有一个固定的ClassLoader，当程序运行时它在内存中完全自行解开，无需先安装
动态生成。可以生成应用其他还未生成类的类，实时创建整个类并可在任何时刻引入JVM
2.0 资源载入
所有资源都通过ClassLoader载入到JVM里，那么在载入资源时当然可以使用ClassLoader，只是对于不同的资源还可以使用一些别的方式载入，例如对于类可以直接new，对于文件可以直接做IO等。 2.1 载入类的几种方法假设有类A和类B，A在方法amethod里需要实例化B，可能的方法有3种。对于载入类的情况，用户需要知道B类的完整名字（包括包名，例如"com.rain.B"）
1. 使用Class静态方法 Class.forName
Class cls = Class.forName("com.rain.B");
B b = (B)cls.newInstance();
2. 使用ClassLoader
/* Step 1. Get ClassLoader */
ClassLoader cl; // 如何获得ClassLoader参考1.6
/* Step 2. Load the class */
Class cls = cl.loadClass("com.rain.B"); // 使用第一步得到的ClassLoader来载入B
/* Step 3. new instance */
B b = (B)cls.newInstance(); // 有B的类得到一个B的实例
3. 直接new
B b = new B();
2.2 文件载入（例如配置文件等）假设在com.rain.A类里想读取文件夹 /com/rain/config 里的文件sys.properties，读取文件可以通过绝对路径或相对路径，绝对路径很简单，在Windows下以盘号开始，在Unix下以"/"开始
对于相对路径，其相对值是相对于ClassLoader的，因为ClassLoader是一棵树，所以这个相对路径和ClassLoader树上的任何一个ClassLoader相对比较后可以找到文件，那么文件就可以找到，当然，读取文件也使用委托模型
1. 直接IO
/**
* 假设当前位置是 "C:/test"，通过执行如下命令来运行A "java com.rain.A"
* 1. 在程序里可以使用绝对路径，Windows下的绝对路径以盘号开始，Unix下以"/"开始
* 2. 也可以使用相对路径，相对路径前面没有"/"
* 因为我们在 "C:/test" 目录下执行程序，程序入口点是"C:/test"，相对路径就
* 是 "com/rain/config/sys.properties"
* （例子中，当前程序的ClassLoader是App ClassLoader，system ClassLoader = 当前的
* 程序的ClassLoader，入口点是"C:/test"）
* 对于ClassLoader树，如果文件在jdk lib下，如果文件在jdk lib/ext下，如果文件在环境变量里，
* 都可以通过相对路径"sys.properties"找到，lib下的文件最先被找到
*/
File f = new File("C:/test/com/rain/config/sys.properties"); // 使用绝对路径
//File f = new File("com/rain/config/sys.properties"); // 使用相对路径
InputStream is = new FileInputStream(f);
如果是配置文件，可以通过java.util.Properties.load(is)将内容读到Properties里，Properties默认认为is的编码是ISO-8859-1，如果配置文件是非英文的，可能出现乱码问题。
2. 使用ClassLoader
/**
* 因为有3种方法得到ClassLoader，对应有如下3种方法读取文件
* 使用的路径是相对于这个ClassLoader的那个点的相对路径，此处只能使用相对路径
*/
InputStream is = null;
is = this.getClass().getClassLoader().getResourceAsStream(
"com/rain/config/sys.properties"); //方法1
//is = Thread.currentThread().getContextClassLoader().getResourceAsStream(
"com/rain/config/sys.properties"); //方法2
//is = ClassLoader.getSystemResourceAsStream("com/rain/config/sys.properties"); //方法3
如果是配置文件，可以通过java.util.Properties.load(is)将内容读到Properties里，这里要注意编码问题。
3. 使用ResourceBundle
ResourceBundle bundle = ResourceBundle.getBoundle("com.rain.config.sys");
这种用法通常用来载入用户的配置文件，关于ResourceBunlde更详细的用法请参考其他文档
总结：有如下3种途径来载入文件
1. 绝对路径 ---> IO
2. 相对路径 ---> IO
---> ClassLoader
3. 资源文件 ---> ResourceBundle
2.3 如何在web应用里载入资源在web应用里当然也可以使用ClassLoader来载入资源，但更常用的情况是使用ServletContext，如下是web目录结构
ContextRoot
|- JSP、HTML、Image等各种文件
|- [WEB-INF]
|- web.xml
|- [lib] Web用到的JAR文件
|- [classes] 类文件
用户程序通常在classes目录下，如果想读取classes目录里的文件，可以使用ClassLoader，如果想读取其他的文件，一般使用ServletContext.getResource()
如果使用ServletContext.getResource(path)方法，路径必须以"/"开始，路径被解释成相对于ContextRoot的路径，此处载入文件的方法和ClassLoader不同，举例"/WEB-INF/web.xml","/download/WebExAgent.rar"
‘叁’ 我手头有一个web系统，很多java class类都是加密的，是用classloader.dll加载
楼主你好，这种错误不在现场调试，没有人可以给出一个正确的答案，而且还是偶尔报错，属于“幽灵事件”，我大致给出一个思路，jvm中类的加载器都遵循双亲委派模型，如果不清楚，网上可以了解下，而tomcat是正统的类加载器架构，如图：
其中WebAppClassLoader会去加载/Webapp/WEB-INF/*中的Java类库，所以，上述报错可能与java环境出错有关，可能java jar包残缺，
并且报错也隐约看出来，我认为是java 环境的问题，楼主看参考解决下，望对你有所帮助！
‘肆’ classloader的原理 有哪些类加载器 为什么要用自定义类加载器
原理之类的，你自己上网看资料吧，不是一两句话说得清的。
至于为什么用自定义类加载器，个人总结了一下可能有下面几点吧，可能不全，也请大家补充：
加密：众所周知，java代码很容易被反编译，如果你需要把自己的代码进行加密，可以先将编译后的代码用某种加密算法加密，然后实现自己的类加载器，负责将这段加密后的代码还原。
从非标准的来源加载代码：例如你的部分字节码是放在数据库中甚至是网络上的，就可以自己写个类加载器，从指定的来源加载类。
动态创建：为了性能等等可能的理由，根据实际情况动态创建代码并执行。
其他（这个理由非常给力吧^_^）
‘伍’ 如何有效的防止Java程序被反编译和破解
由于Java字节码的抽象级别较高，因此它们较容易被反编译。下面介绍了几种常用的方法，用于保护Java字节码不被反编译。通常，这些方法不能够绝对防止程序被反编译，而是加大反编译的难度而已，因为这些方法都有自己的使用环境和弱点。
1.隔离Java程序
最简单的方法就是让用户不能够访问到Java Class程序，这种方法是最根本的方法，具体实现有多种方式。例如，开发人员可以将关键的Java Class放在服务器端，客户端通过访问服务器的相关接口来获得服务，而不是直接访问Class文件。这样黑客就没有办法反编译Class文件。目前，通过接口提供服务的标准和协议也越来越多，例如 HTTP、Web Service、RPC等。但是有很多应用都不适合这种保护方式，例如对于单机运行的程序就无法隔离Java程序。
2.对Class文件进行加密
为了防止Class文件被直接反编译，许多开发人员将一些关键的Class文件进行加密，例如对注册码、序列号管理相关的类等。在使用这些被加密的类之前，程序首先需要对这些类进行解密，而后再将这些类装载到JVM当中。这些类的解密可以由硬件完成，也可以使用软件完成。
在实现时，开发人员往往通过自定义ClassLoader类来完成加密类的装载(注意由于安全性的原因，Applet不能够支持自定义的ClassLoader)。自定义的ClassLoader首先找到加密的类，而后进行解密，最后将解密后的类装载到JVM当中。在这种保护方式中，自定义的ClassLoader是非常关键的类。由于它本身不是被加密的，因此它可能成为黑客最先攻击的目标。如果相关的解密密钥和算法被攻克，那么被加密的类也很容易被解密。
3.转换成本地代码
将程序转换成本地代码也是一种防止反编译的有效方法。因为本地代码往往难以被反编译。开发人员可以选择将整个应用程序转换成本地代码，也可以选择关键模块转换。如果仅仅转换关键部分模块，Java程序在使用这些模块时，需要使用JNI技术进行调用。当然，在使用这种技术保护Java程序的同时，也牺牲了Java的跨平台特性。对于不同的平台，我们需要维护不同版本的本地代码，这将加重软件支持和维护的工作。不过对于一些关键的模块，有时这种方案往往是必要的。为了保证这些本地代码不被修改和替代，通常需要对这些代码进行数字签名。在使用这些本地代码之前，往往需要对这些本地代码进行认证，确保这些代码没有被黑客更改。如果签名检查通过，则调用相关JNI方法。
4.代码混淆
代码混淆是对Class文件进行重新组织和处理，使得处理后的代码与处理前代码完成相同的功能(语义)。但是混淆后的代码很难被反编译，即反编译后得出的代码是非常难懂、晦涩的，因此反编译人员很难得出程序的真正语义。从理论上来说，黑客如果有足够的时间，被混淆的代码仍然可能被破解，甚至目前有些人正在研制反混淆的工具。但是从实际情况来看，由于混淆技术的多元化发展，混淆理论的成熟，经过混淆的Java代码还是能够很好地防止反编译。下面我们会详细介绍混淆技术，因为混淆是一种保护Java程序的重要技术。
‘陆’ 【转】如何保护Java代码
以下从技术角度就常见的保护措施 和常用工具来看看如何有效保护java代码：1. 将java包装成exe 特点：将jar包装成可执行文件，便于使用，但对java程序没有任何保护。不要以为生成了exe就和普通可执行文件效果一样了。这些包装成exe的程序运行时都会将jar文件释放到临时目录，很容易获取。常用的工具有exe4j、jsmooth、NativeJ等等。jsmooth生成的exe运行时临时目录在exe所在目录中或是用户临时目录 中；exe4j生成的exe运行时临时目录在用户临时目录中；NativeJ生成的exe直接用winrar打开，然后用zip格式修复成一个jar文件，就得到了原文件。如果只是为了使用和发布方便，不需要保护java代码，使用这些工具是很好的选择。2. java混淆器特点：使用一种或多种处理方式将class文件、java源代码进行混淆处理后生成新的class，使混淆后的代码不易被反编译，而反编译后的代码难以阅 读和理解。这类混淆器工具很多，而且也很有成效。缺点：虽然混淆的代码反编译后不易读懂，但对于有经验的人或是多花些时间，还是能找到或计算出你代码中隐藏的敏感内容，而且在很多应用中不是全部代码都能混淆的，往往一些关键的库、类名、方法名、变量名等因使用要求的限制反而还不能混淆。3. 隔离java程序到服务端特点：把java程序放到服务端，让用户不能访问到class文件和相关配套文件，客户端只通过接口访问。这种方式在客户/服务模式的应用中能较好地保护java代码。缺点是：必须是客户/服务模式，这种特点限制了此种方式的使用范围；客户端因为逻辑的暴露始终是较为薄弱的环节，所以访问接口时一般都需要安全性认证。4. java加密保护特点：自定义ClassLoader，将class文件和相关文件加密，运行时由此ClassLoader解密相关文件并装载类，要起到保护作用必须自定 义本地代码执行器将自定义ClassLoader和加密解密的相关类和配套文件也保护起来。此种方式能很有效地保护java代码。缺点：可以通过替换JRE包中与类装载相关的java类或虚拟机动态库截获java字节码。 jar2exe属于这类工具。5. 提前编译技术(AOT) 特点：将java代码静态编译成本地机器码，脱离通用JRE。此种方式能够非常有效地保护java代码，且程序启动比通用JVM快一点。具有代表性的是GNU的gcj，可以做到对java代码完全提前编译，但gcj存在诸多局限性，如：对JRE 5不能完整支持、不支持JRE 6及以后的版本。由于java平台的复杂性，做到能及时支持最新java版本和JRE的完全提前编译是非常困难的，所以这类工具往往采取灵活方式，该用即时编译的地方还是 要用，成为提前编译和即时编译的混合体。缺点：由于与通用JRE的差异和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；只能使用此种工具提供的一个运行环境，如果工具更新滞后或你需要特定版本的JRE，有可能得不到此种工具的支持。 Excelsior JET属于这类工具。6. 使用jni方式保护特点：将敏感的方法和数据通过jni方式处理。此种方式和“隔离java程序到服务端”有些类似，可以看作把需要保护的代码和数据“隔离”到动态库中，不同的是可以在单机程序中运用。缺点和上述“隔离java程序到服务端”类似。7. 不脱离JRE的综合方式保护特点：非提前编译，不脱离JRE，采用多种软保护方式，从多方面防止java程序被窃取。此种方式由于采取了多种保护措施，比如自定义执行器和装载器、加密、JNI、安全性检测、生成可执行文件等等，使保护力度大大增强，同样能够非常有效地保护java代码。缺点：由于jar文件存在方式的改变和java运用中的复杂性，并非java程序中的所有jar都能得到完全的保护；很有可能并不支持所有的JRE版本。 JXMaker属于此类工具。8. 用加密锁硬件保护特点：使用与硬件相关的专用程序将java虚拟机启动程序加壳，将虚拟机配套文件和java程序加密，启动的是加壳程序，由加壳程序建立一个与硬件相关的 受保护的运行环境，为了加强安全性可以和加密锁内植入的程序互动。此种方式与以上“不脱离JRE的综合方式保护”相似，只是使用了专用硬件设备，也能很好地保护java代码。缺点：有人认为加密锁用户使用上不太方便，且每个安装需要附带一个。从以上描述中我们可以看出：1. 各种保护方式都有其优缺点，应根据实际选用2. 要更好地保护java代码应该使用综合的保护措施3. 单机环境中要真正有效保护java代码，必须要有本地代码程序配合当然，安全都是相对的，一方面看你的保护措施和使用的工具能达到的程度，一方面看黑客的意愿和能力，不能只从技术上保护知识产权。总之，在java 代码保护方面可以采取各种可能的方式，不可拘泥于那些条条框框。
‘柒’ 最新我公司在使用部署一公司的java web应用程序发现他们的所有的class无法反编译，怎么做到的
怎么可能不能反编译，除非他的代码不想让机器运行。
java加密无非是模糊化或者是修改classloader加密。前一种直接反编译，只是不容易看而已。
后一种先反编译classloader，研究加密过程，再解密反编译即可。
‘捌’ 如何使class文件不被反编译呢
想不被反编译是不可能的。混淆器可以吧所有变量名，函数名，类名（系统类，函数名不变）统统用一两个字母代替，可以缩短代码长度，并且被反编译以后难以理解含义增加阅读难度。
‘玖’ javaclass类加密后 如何部署到tomcat
1.使用加密程序对classes下所有文件加密，加密之后所有的class文件后缀变为uikoo9，可以自己修改源代码
2.将原classes文件夹删除，将加密后的classes文件夹复制进去
3.修改context.xml
4.tomcat\lib下添加loader.class
5.启动tomcat！