正如它们的名字所说明的：NoClassDefFoundError是一个错误(Error)，而ClassNOtFoundException是一个异常，在Java中错误和异常是有差别的，我们能够从异常中恢复程序但却不应该尝试从错误中恢复程序。
ClassNotFoundException的产生原因：
Java支持使用Class.forName方法来动态地载入类。随意一个类的类名假设被作为參数传递给这种方法都将导致该类被载入到JVM内存中。假设这个类在类路径中没有被找到，那么此时就会在执行时抛出ClassNotFoundException异常。
要解决问题非常easy，唯一须要做的就是要确保所需的类连同它依赖的包存在于类路径中。当Class.forName被调用的时候。类载入器会查找类路径中的类，假设找到了那么这个类就会被成功载入，假设没找到。那么就会抛出ClassNotFountException。
除了Class.forName，还有例如以下情况
- ClassLoader.loadClass、
- ClassLOader.findSystemClass
在动态载入类到内存中的时候也可能会抛出这个异常。
另外另一个导致ClassNotFoundException的原因就是：当一个类已经某个类载入器载入到内存中了。此时另一个类载入器又尝试着动态地从同一个包中载入这个类。
因为类的动态载入在某种程度上是被开发人员所控制的，所以他能够选择catch这个异常然后採取对应的补救措施。有些程序可能希望忽略这个异常而採取其它方法。
另一些程序则会终止程序然后让用户再次尝试前做点事情。
NoClassDefFoundError产生的原因：
在类的主动使用中。假设JVM或者ClassLoader实例尝试载入类的时候却找不到类的定义。
要查找的类在编译的时候是存在的，执行的时候却找不到了。
因为NoClassDefFoundError是有JVM引起的。所以不应该尝试捕捉这个错误。
解决问题的办法就是：查找那些在开发期间存在于类路径下但在执行期间却不在类路径下的类。
另：
ClassNotFoundException 发生在类的载入（装入）阶段。
类的载入
载入.class文件的方式
- 从本地系统中直接载入
- 通过网络下载.class文件
- 从zip，jar等归纳文件里载入.class文件
- 从专有数据库中提取.class文件
- 将java源文件动态编译为.class文件
当应用程序试图通过类的字符串名称，使用常规的【三种方法】装入类。但却找不到指定名称的类定义时就抛出该异常。
NoClassDefFoundError 发生在类的初始化阶段 ，那什么情况下会导致类的初始化呢？
主动使用（六种）
- 创建类的实例
- 訪问某个类或接口的静态变量，或者对该静态变量赋值
- 调用类的静态方法
- 反射（如Class.forName("com.lang.String")
- 初始化一个类的子类
- Java虚拟机启动时被标为启动类的类
当眼下执行的类已经编译。可是找不到它的定义时，也就是说你假设编译了一个类B。在类A中调用，编译完毕以后，你又删除掉B，执行A（类的主动使用）的时候那么就会出现这个错误，另外能够发现NoClassDefFoundError 的产生也伴随着ClassNotFoundException，这也非常好解释。类的初始化。肯定要先进行类载入和类连接两步的。总结就是例如以下：
- 载入时从外存储器找不到须要的class就出现ClassNotFoundException
- 初始化时从内存找不到须要的class就出现NoClassDefFoundError
附：
NoClassDefFoundError 解决的三种方法：
1. Simple example of NoClassDefFoundError is class belongs to a jar and jar was not added into classpath or sometime jar’s name has been changed by someone like in my case one of my colleague has changed tibco.jar into tibco_v3.jar and by program is failing with java.lang.NoClassDefFoundError and I was wondering what’s wrong.
首先是类在执行的时候依赖于其他的一个jar包。可是该jar包没有载入到classpath中或者是该jar包的名字被其他人改了，就像我的一个样例tibo.jar改为了tibco_v3.jar…….
2. Class is not in Classpath, there is no sure shot way of knowing it but many a times you can just have a look to print System.getproperty(”java.classpath“)and it will print the classpath from there you can at least get an idea of your actual runtime classpath.
执行的类不在classpath中。这个问题没有一个确定的方法去知道。可是非常多时候你能够通过System.getproperty(”java.classpath“)方法，该方法能让你至少能够领略到实际存在的执行期间的classpath。
3. Just try to run with explicitly -classpath option with the classpath you think will work and if its working then it’s
sure short sign that some one is overriding java classpath.
试着通过-classpath命令明白指出你觉得正确的classpath。假设可以正常运行的话就说明你使用的classpath是正确的，而系统中的classpath已经被修该过了。
