JVM中的类加载器

在工作中遇到了到底是使用Thread.currentThread().getContextClassLoader()还是 getClass().getClassLoader()来获得当前类的加载器的问题，在网上搜了很多资料，自己总结了一下：
1、这两种方法中 使用Thread.currentThread().getContextClassLoader()来获得当前类加载器更为安全，而getClass().getClassLoader()的这种方法一般用在getResource，因为你想要获取某个资源文件的时候，这个资源文件的位置是相对固定的。
2、JVM类加载有一种委托机制，即JVM中类加载器都有一个层次结构，即每一个类加载器都有一个父类加载器，当被要求加载一个类时，首先会委托给其父类进行加载，当父类无法成功加载时则由自身加载。然而，这种委托机制也不是都能顺利执行：通常发生在有些JVM核心代码必须动态加载由应用程序开发人员提供的资源时。以JNDI举例：它的核心内容（从J2SE1.3开始）在rt.jar中的引导类中实现了，但是这些JNDI核心类可能加载由独立厂商实现和部署在应用程序的classpath中的JNDI提供者。这个场景要求一个父类加载器（这个例子中的原始类加载器，即加载rt.jar的加载器）去加载一个在它的子类加载器（系统类加载器）中可见的类。此时通常的J2SE委托机制不能工作，解决办法是让JNDI核心类使用线程上下文加载器，从而有效建立一条与类加载器层次结构相反方向的“通道”达到正确的委托。