在閱讀spring boot啟動時候的源碼中，發現獲取classLoader使用的是getContextClassLoader于是乎產生了疑問，這種獲取ClassLoader的方式與我們最常見的通過Class.getClassLoader二者有什么區別？都是在什么場景下使用呢？
首先來看看getClassLoader()方法的注釋：
Returns the class loader for the class. Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class was loaded by the bootstrap class loader.
主要的意思是getClassLoader()返回該類的類加載器，如果是bootstrap加載器加載的類返回Null，這種機制主要是為了安全考慮bootstrap是用來加載jvm核心庫的加載器不允許暴露給用戶操作，可能會引起類沖突的問題。
再來看一下getContextClassLoader()方法的說明：
Sets the context ClassLoader for this Thread. The context ClassLoader can be set when a thread is created, and allows the creator of the thread to provide the appropriate class loader, through getContextClassLoader, to code running in the thread when loading classes and resources.
這個方法返回叫線程上下文類加載器。這個加載器的類型指定的工作交給了線程創建者，創建者在創建線程之后用對應的setContextClassLoader()方法將適合的類加載器設置到線程中，那么線程中的代碼就可以通過getContextClassLoader()獲取到這個類加載器來加載類或者資源。如果不設置默認是系統類加載器就是 app ClassLoader()。
那么這個getContextLoader()方法在什么場景下使用呢？ 因為很多框架為了做類的隔離會通過不同的ClassLoader來做類的隔離。假設框架提供了一個可擴展的服務接口這個接口的類加載器是app ClassLoader，但是這個接口是現實則交給使用者來擴展，那么實現類很有可能被自定義的ClassLoader加載導致appClassLoader無法找到實現類。如果在框架的層面希望能夠獲取到接口實現類就需要將實現類用getContextClassLoader獲得的ClassLoader來加載。
總之，getContextClassLoader是原有代理類加載模式的一種補充。提供一種在子ClassLoader加載的類中獲取父ClassLoader的實例來操作父加載器加載類的方法。
)
