Что является уникальностью загрузки класса в JVM

Уникальность загрузки класса в JVM

Уникальность загрузки класса в JVM определяется тройкой параметров: имя класса, пакет и class loader, который его загрузил. Это означает, что два класса с одинаковым полным именем, но загруженные разными class loaders, считаются разными типами в JVM.

Основной концепт: ClassLoader Identity

Каждый класс в JVM идентифицируется уникально по паре (FullClassName, ClassLoader):

public class ClassLoaderIdentity {
    public static void main(String[] args) {
        // Один и тот же класс, загруженный разными loaders
        ClassLoader loader1 = 
            new URLClassLoader(new URL[]{});
        ClassLoader loader2 = 
            new URLClassLoader(new URL[]{});
        
        // Хотя имена одинаковые, это разные классы!
        Class<?> class1 = loader1.loadClass("com.example.MyClass");
        Class<?> class2 = loader2.loadClass("com.example.MyClass");
        
        System.out.println(class1 == class2); // false!
        System.out.println(class1.equals(class2)); // false!
    }
}

Это фундаментальное правило влияет на многие аспекты JVM и может привести к ошибкам, если его не понимать.

Иерархия Class Loaders

JVM использует иерархию class loaders, каждый из которых отвечает за загрузку классов из определенного источника:

public class ClassLoaderHierarchy {
    public static void main(String[] args) {
        // Bootstrap ClassLoader (ядро Java)
        System.out.println(Object.class.getClassLoader()); // null
        
        // Extension ClassLoader (или Platform ClassLoader в Java 9+)
        ClassLoader extLoader = ClassLoader.getSystemClassLoader()
            .getParent();
        System.out.println("Extension: " + extLoader);
        
        // Application ClassLoader
        ClassLoader appLoader = 
            ClassLoader.getSystemClassLoader();
        System.out.println("App: " + appLoader);
        
        // Текущего класса loader
        ClassLoader currentLoader = 
            ClassLoaderHierarchy.class.getClassLoader();
        System.out.println("Current: " + currentLoader);
    }
}

Результат:

Bootstrap: null (Bootstrap ClassLoader нельзя получить из Java)
Extension: sun.misc.Launcher$ExtClassLoader@...
App: sun.misc.Launcher$AppClassLoader@...
Current: sun.misc.Launcher$AppClassLoader@...

Delegation Model (Модель делегирования)

Класс loaders работают по принципу делегирования: сначала запрашивают parent loader, и только если тот не может загрузить класс, загружают сами:

public class DelegationModelDemo {
    public static void main(String[] args) 
            throws ClassNotFoundException {
        ClassLoader myLoader = 
            new CustomClassLoader("MyLoader");
        
        // 1. MyLoader спрашивает parent (AppClassLoader)
        // 2. AppClassLoader спрашивает parent (PlatformClassLoader)
        // 3. PlatformClassLoader спрашивает parent (Bootstrap)
        // 4. Bootstrap смотрит в rt.jar, не находит
        // 5. Идет обратно по цепочке
        // 6. MyLoader загружает из своего источника
        
        Class<?> cls = myLoader.loadClass(
            "com.custom.MyClass");
        System.out.println("Loaded by: " + 
            cls.getClassLoader());
    }
}

class CustomClassLoader extends ClassLoader {
    private String name;
    
    public CustomClassLoader(String name) {
        super();
        this.name = name;
    }
    
    @Override
    protected Class<?> findClass(String name) 
            throws ClassNotFoundException {
        System.out.println(this.name + 
            " trying to load " + name);
        // Логика загрузки класса из бинарного файла
        return super.findClass(name);
    }
}

Проблемы с уникальностью класса

1. ClassCastException между разными loaders

public class ClassLoaderCastIssue {
    static class CustomLoader extends URLClassLoader {
        public CustomLoader(URL[] urls) {
            super(urls);
        }
    }
    
    public static void main(String[] args) 
            throws Exception {
        // Загружаем SharedClass двумя разными loaders
        CustomLoader loader1 = new CustomLoader(new URL[]{});
        CustomLoader loader2 = new CustomLoader(new URL[]{});
        
        Object obj1 = loader1.loadClass(
            "com.example.SharedClass").newInstance();
        
        // Пытаемся привести к другому классу
        try {
            com.example.SharedClass casted = 
                (com.example.SharedClass) obj1; // ClassCastException!
        } catch (ClassCastException e) {
            System.out.println(
                "Cannot cast: " + e.getMessage());
        }
    }
}

2. Проблемы с instanceof

public class InstanceofProblem {
    public static void main(String[] args) 
            throws Exception {
        ClassLoader loader1 = 
            new URLClassLoader(new URL[]{});
        ClassLoader loader2 = 
            new URLClassLoader(new URL[]{});
        
        Object obj1 = loader1.loadClass(
            "com.example.MyClass").newInstance();
        Class<?> class2 = loader2.loadClass(
            "com.example.MyClass");
        
        // instanceof вернет false, хотя по именам
        // это "один и тот же" класс!
        System.out.println(obj1 instanceof 
            Object); // true
        System.out.println("obj1 instanceof 
            MyClass: " + (obj1 instanceof 
            com.example.MyClass)); // false!
    }
}

OSGi и Модульные системы

При использовании OSGi (Open Services Gateway initiative) уникальность класса становится критичной:

public class OSGiExample {
    // В OSGi каждый бандл (bundle) имеет свой ClassLoader
    // Bundle A может экспортировать версию 1.0 класса X
    // Bundle B может экспортировать версию 2.0 класса X
    // Они остаются разными в памяти JVM
    
    // Это позволяет разным версиям библиотек
    // сосуществовать в одной JVM
}

Как избежать проблем

1. Используй Interface Segregation

public class SafeClassLoading {
    // Вместо прямого использования класса,
    // используй интерфейс, загруженный parent loader
    
    interface DataProcessor {
        void process();
    }
    
    static class Impl implements DataProcessor {
        @Override
        public void process() {
            System.out.println("Processing...");
        }
    }
    
    public static void main(String[] args) 
            throws Exception {
        ClassLoader loader = 
            new URLClassLoader(new URL[]{});
        
        // Загружаем только реализацию
        Class<?> implClass = loader.loadClass(
            "com.example.Impl");
        
        // Приводим к интерфейсу, который
        // известен app loader
        DataProcessor processor = 
            (DataProcessor) implClass.newInstance();
        processor.process();
    }
}

2. Явная проверка ClassLoader

public class ExplicitLoaderCheck {
    public static boolean isSameClass(
            Class<?> cls1, Class<?> cls2) {
        // Проверяем не только имя, но и loader
        return cls1.getName().equals(cls2.getName())
            && cls1.getClassLoader() == 
                cls2.getClassLoader();
    }
    
    public static void main(String[] args) 
            throws Exception {
        ClassLoader loader1 = 
            new URLClassLoader(new URL[]{});
        
        Class<?> cls1 = String.class;
        Class<?> cls2 = loader1.loadClass("java.lang.String");
        
        System.out.println(
            isSameClass(cls1, cls2)); // true
        System.out.println(
            cls1 == cls2); // true (String всегда
                           // загружается Bootstrap loader)
    }
}

3. Контролируй Context ClassLoader

public class ContextLoaderControl {
    public static void main(String[] args) {
        ClassLoader originalLoader = 
            Thread.currentThread().getContextClassLoader();
        
        try {
            // Меняем context loader для потока
            ClassLoader newLoader = 
                new URLClassLoader(new URL[]{});
            Thread.currentThread()
                .setContextClassLoader(newLoader);
            
            // Теперь многие API используют этот loader
            doWork();
        } finally {
            // Восстанавливаем оригинальный
            Thread.currentThread()
                .setContextClassLoader(
                    originalLoader);
        }
    }
    
    static void doWork() {
        // Будет использовать context loader текущего thread
    }
}

Практические сценарии

1. Приложение контейнеры (Tomcat, JBoss) Каждое веб-приложение имеет свой ClassLoader, что позволяет разным версиям одной библиотеки существовать в одном JVM.

2. Plugin системы Плагины загружаются отдельными ClassLoaders для изоляции и переиспользования без перезагрузки приложения.

3. Java Modules (Java 9+) Модули используют собственный загрузчик для управления visibility и версионирования.

Ключевой вывод: Уникальность класса в JVM определяется не только его полным именем, но и ClassLoader, который его загрузил. Это мощный механизм для изоляции и версионирования, но требует понимания для избежания подводных камней в production среде.