Разница между загрузчиком классов контекста потока и обычным загрузчиком классов

В чем разница между загрузчиком классов контекста потока и обычным загрузчиком классов?

То есть, если Thread.currentThread().getContextClassLoader()и getClass().getClassLoader()вернуть разные объекты загрузчика классов, какой из них будет использоваться?

Каждый класс будет использовать свой собственный загрузчик классов для загрузки других классов. Так что если ClassA.classссылки ClassB.classтогда ClassBдолжны быть на пути к классам загрузчика классовClassA или его родителей.

Загрузчик классов контекста потока является текущим загрузчиком классов для текущего потока. Объект может быть создан из класса ClassLoaderCи затем передан в поток, принадлежащий ClassLoaderD. В этом случае объект необходимо использовать Thread.currentThread().getContextClassLoader()напрямую, если он хочет загрузить ресурсы, которые недоступны в его собственном загрузчике классов.

Это не отвечает на первоначальный вопрос, но поскольку вопрос высоко ранжируется и связывается для любого ContextClassLoaderзапроса, я думаю, что важно ответить на связанный вопрос о том, когда следует использовать загрузчик класса контекста. Краткий ответ: никогда не используйте загрузчик классов контекста ! Но установите его, getClass().getClassLoader()когда вам нужно вызвать метод, который отсутствуетClassLoader параметр.

Когда код из одного класса просит загрузить другой класс, правильный загрузчик класса, который нужно использовать, является тем же загрузчиком класса, что и класс вызывающей стороны (т. Е. getClass().getClassLoader()). Именно так все и работает в 99,9% случаев, потому что именно это делает сама JVM. при первом создании экземпляра нового класса, вызове статического метода или обращении к статическому полю.

Когда вы хотите создать класс с использованием отражения (например, при десериализации или загрузке настраиваемого именованного класса), библиотека, которая выполняет отражение, должна всегда спрашивать приложение, какой загрузчик классов использовать, получая в ClassLoaderкачестве параметра из приложения. Приложение (которое знает все классы, которые нужно построить) должно передать егоgetClass().getClassLoader() .

Любой другой способ получить загрузчик классов неверен. Если библиотека использует такие хаки, как Thread.getContextClassLoader(), sun.misc.VM.latestUserDefinedLoader()или sun.reflect.Reflection.getCallerClass()это ошибка, вызванная недостатком API. По сути, Thread.getContextClassLoader()существует только потому, что тот, кто разработал ObjectInputStreamAPI, забыл принятьClassLoader в качестве параметра, и эта ошибка преследует сообщество Java и по сей день.

Тем не менее, многие классы JDK используют один из нескольких хаков, чтобы угадать какой-либо загрузчик классов. Некоторые используют ContextClassLoader(что дает сбой, когда вы запускаете разные приложения в общем пуле потоков, или когда вы покидаете ContextClassLoader null), некоторые обходят стек (что не удается, когда прямой вызывающий класс сам является библиотекой), другие используют загрузчик системного класса (что нормально, если задокументировано использование только классов в CLASSPATH) или загрузчике классов, а некоторые используют непредсказуемую комбинацию вышеперечисленных методов (что только делает вещи более запутанными). Это привело к сильному рыданию и скрежету зубов.

При использовании такого API, сначала попробуйте найти перегрузку метода, который принимает загрузчик классов в качестве параметра . Если разумного метода нет, попробуйте установить ContextClassLoaderвызов API before (и затем сбросить его):

ClassLoader originalClassLoader = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
    // call some API that uses reflection without taking ClassLoader param
} finally {
    Thread.currentThread().setContextClassLoader(originalClassLoader);
}

На javaworld.com есть статья, которая объясняет разницу => Какой ClassLoader вы должны использовать

(1)

Загрузчики классов контекста потока обеспечивают заднюю дверь вокруг схемы делегирования загрузки классов.

Возьмем, к примеру, JNDI: его внутренности реализованы классами начальной загрузки в rt.jar (начиная с J2SE 1.3), но эти основные классы JNDI могут загружать поставщиков JNDI, реализованных независимыми поставщиками и потенциально развернутых в -classpath приложения. В этом сценарии родительский загрузчик классов (в данном случае первичный) загружает класс, видимый для одного из его дочерних загрузчиков (например, системный). Обычное делегирование J2SE не работает, и обходной путь состоит в том, чтобы основные классы JNDI использовали загрузчики контекста потока, таким образом эффективно "туннелируя" через иерархию загрузчика классов в направлении, противоположном правильному делегированию.

(2) из ​​того же источника:

Эта путаница, вероятно, останется с Java на некоторое время. Возьмите любой J2SE API с любой динамической загрузкой ресурсов и попытайтесь угадать, какую стратегию загрузки он использует. Вот выборка:

• JNDI использует контекстные загрузчики классов
• Class.getResource () и Class.forName () используют текущий загрузчик классов
• JAXP использует контекстные загрузчики классов (начиная с J2SE 1.4)
• java.util.ResourceBundle использует текущий загрузчик классов вызывающей стороны
• Обработчики протокола URL, указанные через системное свойство java.protocol.handler.pkgs, ищутся только в загрузчике и в системных загрузчиках классов
• Java Serialization API использует текущий загрузчик классов вызывающего по умолчанию

Если добавить ответ @David Roussel, классы могут загружаться несколькими загрузчиками классов.

Давайте разберемся, как работает загрузчик классов .

Из блога Джавина Пола в javarevisited:

ClassLoader следует трем принципам.

Принцип делегирования

Класс загружается в Java, когда это необходимо. Предположим, у вас есть специфичный для приложения класс с именем Abc.class, первый запрос на загрузку этого класса поступит в Application ClassLoader, который делегирует его родительскому расширению ClassLoader, которое далее делегирует Primordial или загрузчику классов Bootstrap

• Bootstrap ClassLoader отвечает за загрузку стандартных файлов классов JDK из rt.jar и является родителем всех загрузчиков классов в Java. Загрузчик класса Bootstrap не имеет родителей.

• Расширение ClassLoader делегирует запрос на загрузку класса своему родителю, Bootstrap и, в случае неудачи , загружает каталог формы jre / lib / ext или любой другой каталог, указанный системным свойством java.ext.dirs.

• Загрузчик классов системы или приложения и отвечает за загрузку определенных классов приложения из переменной среды CLASSPATH, параметра командной строки -classpath или -cp, атрибута Class-Path файла Manifest внутри JAR.

• Загрузчик классов приложений является дочерним по отношению к Extension ClassLoader и реализуется sun.misc.Launcher$AppClassLoaderклассом.

ПРИМЕЧАНИЕ. За исключением загрузчика классов Bootstrap , который реализован на родном языке в основном на C, все загрузчики классов Java реализованы с использованием java.lang.ClassLoader.

Принцип видимости

Согласно принципу видимости, Child ClassLoader может видеть класс, загруженный Parent ClassLoader, но, наоборот, это не так.

Принцип уникальности

Согласно этому принципу класс, загруженный Parent, не должен снова загружаться Child ClassLoader