От этой темы :
Class.getClassLoader()
возвращает ClassLoader
, который загрузил класс, для которого он был вызван.
Thread.getContextClassLoader()
возвращает ClassLoader
, установленный в качестве контекста ClassLoader
для Thread
, к которому он вызывается, что может отличаться от ClassLoader
, который загружал сам класс Thread, если метод Thread * setContextClassLoader(ClassLoader)
был вызван.
Это можно использовать, чтобы позволить объекту, запускающему поток, указать ClassLoader
, который должны использовать объекты, запущенные в потоке, но для работы этого требуется взаимодействие некоторых из этих объектов.
Так что, если вам интересно, почему существует 3 вызова API
Thread<instance>.getContextClassLoader()
Thread<instance>.getClassLoader()
Class<instance>.getClassLoader()
, вы можете найти в этом Найти выход из лабиринта ClassLoader ответ.
Почему загрузчики классов контекста потока существуют в первую очередь? Они были введены в J2SE без особой помпы. Определенное отсутствие надлежащего руководства и документации от Sun Microsystems, вероятно, объясняет, почему многие разработчики считают их запутанными.
По правде говоря, контекстные загрузчики классов обеспечивают заднюю дверь вокруг схемы делегирования загрузки классов, также введенной в J2SE. Обычно все загрузчики классов в JVM организованы в иерархию, так что каждый загрузчик классов (за исключением первоначального загрузчика классов, который загружает всю JVM) имеет одного родителя.
[...]
Что еще хуже, некоторые серверы приложений устанавливают контекст и текущие загрузчики классов для разных экземпляров ClassLoader, которые имеют одинаковые пути к классам и, тем не менее, не связаны как родительские и дочерние делегирования.