雙親委派模型的破壞
雙親委派模型的第一次“被破壞”其實發生在雙親委派模型出現之前–即JDK1.2釋出之前。由於雙親委派模型是在JDK1.2之後才被引入的，而類載入器和抽象類java.lang.ClassLoader則是JDK1.0時候就已經存在，面對已經存在 的使用者自定義類載入器的實現程式碼，Java設計者引入雙親委派模型時不得不做出一些妥協。為了向前相容，JDK1.2之後的java.lang.ClassLoader添加了一個新的proceted方法findClass()，在此之前，使用者去繼承java.lang.ClassLoader的唯一目的就是重寫loadClass()方法，因為虛擬在進行類載入的時候會呼叫載入器的私有方法loadClassInternal()，而這個方法的唯一邏輯就是去呼叫自己的loadClass()。JDK1.2之後已不再提倡使用者再去覆蓋loadClass()方法，應當把自己的類載入邏輯寫到findClass()方法中，在loadClass()方法的邏輯裡，如果父類載入器載入失敗，則會呼叫自己的findClass()方法來完成載入，這樣就可以保證新寫出來的類載入器是符合雙親委派模型的。
雙親委派模型的第二次“被破壞”是這個模型自身的缺陷所導致的，雙親委派模型很好地解決了各個類載入器的基礎類統一問題(越基礎的類由越上層的載入器進行載入)，基礎類之所以被稱為“基礎”，是因為它們總是作為被呼叫程式碼呼叫的API。但是，如果基礎類又要呼叫使用者的程式碼，那該怎麼辦呢。
這並非是不可能的事情，一個典型的例子便是JNDI服務，它的程式碼由啟動類載入器去載入(在JDK1.3時放進rt.jar)，但JNDI的目的就是對資源進行集中管理和查詢，它需要呼叫獨立廠商實現部部署在應用程式的classpath下的JNDI介面提供者(SPI, Service Provider Interface)的程式碼，但啟動類載入器不可能“認識”之些程式碼，該怎麼辦？
為了解決這個困境，Java設計團隊只好引入了一個不太優雅的設計：執行緒上下檔案類載入器(Thread Context ClassLoader)。這個類載入器可以通過java.lang.Thread類的setContextClassLoader()方法進行設定，如果建立執行緒時還未設定，它將會從父執行緒中繼承一個；如果在應用程式的全域性範圍內都沒有設定過，那麼這個類載入器預設就是應用程式類載入器。了有執行緒上下文類載入器，JNDI服務使用這個執行緒上下文類載入器去載入所需要的SPI程式碼，也就是父類載入器請求子類載入器去完成類載入動作，這種行為實際上就是打通了雙親委派模型的層次結構來逆向使用類載入器，已經違背了雙親委派模型，但這也是無可奈何的事情。Java中所有涉及SPI的載入動作基本上都採用這種方式，例如JNDI,JDBC,JCE,JAXB和JBI等。
雙親委派模型的第三次“被破壞”是由於使用者對程式的動態性的追求導致的，例如OSGi的出現。在OSGi環境下，類載入器不再是雙親委派模型中的樹狀結構，而是進一步發展為網狀結構。