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

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

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

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

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

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

Любой другой способ получить загрузчик классов неверен. Если библиотека использует такие хаки, как _ 7_, _ 8_ или _ 9_ это ошибка, вызванная недостатком API. По сути, Thread.getContextClassLoader() существует только потому, что разработчик ObjectInputStream API забыл принять ClassLoader в качестве параметра, и эта ошибка не дает покоя сообществу Java по сей день.

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

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

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);
}

На infoworld.com есть статья, объясняющая разницу = ›Какой загрузчик классов следует использовать

(1)

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

Возьмем, к примеру, JNDI: его внутренности реализованы с помощью классов начальной загрузки в rt.jar (начиная с J2SE 1.3), но эти базовые классы JNDI могут загружать поставщиков JNDI, реализованных независимыми поставщиками и потенциально развернутых в пути к классам приложения. Этот сценарий требует, чтобы родительский загрузчик классов (в данном случае первичный) загружал класс, видимый одному из его дочерних загрузчиков классов (например, системному). Обычное делегирование 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, классы могут загружаться несколькими загрузчиками классов.

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

Из блога javin paul на javarevisited:

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

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

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

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

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

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

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

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

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

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

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

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