Определяем все классы, которые использует приложение на Java

[@Askell]

Проверка, работают ли комментарии

[@buxley]

Проверка, работают ли ответы на комментарии

[@buxley]

Проверка, работают ли комментарии

[@allex]

А заказчика не смущало, что на разных прогонах приложения, вообще говоря, может загружаться разный набор классов?

[@Askell]

А что понимать под прогонами для бизнес приложения, которое
1) непрерывно крутится на веб-сервере
2) с определенной периодичностью (каждую ночь/неделю/месяц/...) запускаются пакетные задания по обработке накопившихся транзакций?
Заказчику и нужно было определить только реально используемые классы на реально работающем приложении. Все подряд классы можно было и статическим анализом исходникв (ну + еще часть имен классов в properties файлах прописана) получить. А тут берем приложение, запускаем его в режиме сбора статистики на неделю/месяц/сколько там наибольший период сбора статистики (ну либо прогоняем на тестовом сервере все периодические задания сразу + сажаем пару тестеров за веб интерфейс) и на выходе имеем лог для анализа.

[@allex]

Для примера, если это приложение 29 февраля делает что-то особенное с помощью отдельного класса, то ждать придётся довольно долго :)
Я просто хочу обратить внимание, что этот список, вообще говоря, не полный. Для некоторых целей это может оказаться существенным.

[@romanmir]

Да, можно еще вот так попробовать, это просто выбрасывает названия классов для обьектов на экран, если использовать -histo:live, то показывает те классы, для которых обьекты еще живут в памяти, если параметер -histo, то распечатает все классы, которые живут или жили. Так же показывает кол-во памяти ими занятое и кол-во обьектов (instances).

jmap -histo <PID>

[@mark_stein]

Спасибо, очень интересно.

Не знал, что бывает JAVA_TOOL_OPTIONS и даже пару раз удивлялся почему переменные посаженные в JAVA_OPTS не видны если запускать из eclipsе.

[@ebgans]

есть способ попроще: ClassLoader хранит список загруженных классов в приватной переменной classes:

    // The classes loaded by this class loader. The only purpose of this table
    // is to keep the classes from being GC'ed until the loader is GC'ed.
    private final Vector<Class<?>> classes = new Vector<>();

к ней можно достучаться через reflection и посмотреть что загружено. Примерно так:

        // get access to the private variable ClassLoader.classes
        Field fld = ClassLoader.class.getDeclaredField("classes");
        fld.setAccessible(true);

        // list classes loaded by the application class loader		
        ClassLoader appLoader = MyApp.class.getClassLoader();
        Vector<Class<?>> classes = (Vector<Class<?>>) fld.get(appLoader);
        Map<String, Class<?>> map = new HashMap<String, Class<?>>();
        for (Class<?> cls : classes) {
            System.out.println(cls);
        }

можно сгруппировать загруженные классы по джарам:

    // classes groupped by jar
    Map<String, Collection<Class> > classesByJar = new HashMap<String, Collection<Class>>();
    for(Class clz : loadedClasses){
        String jarLocation = clz.getProtectionDomain().getCodeSource().getLocation().toString();
        Collection<Class>  jarClasses = classesByJar.get(jarLocation );
        if(jarClasses == null) {
            jarClasses = new ArrayList<Class>();
            classesByJar.put(jarLocation, jarClasses);
        }
        jarClasses.add(clz);
    }

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

[@randoom]

Я только одного не понимаю — а чем не устроило использование одного из тысяч тулов мониторинга JVM?
Например VisualVM умеет делать срез для любого Java приложения и показывать какие классы в нем сейчас загружены.

[@Askell]

В том то и дело что в рамках поставленной задачи нужен не мгновенный срез, а статистика за продолжительный период по множеству запущенных инстансов JVM (причем некоторые из них порождаются другими классами экзотическими методами типа Runtime.exec(«java ...»)) При этом есть задачи которые запускаются раз в неделю или раз в месяц. И задача звучала именно так — чтобы приложение само складывало в лог все загруженные классы, я так понял чтобы его можно было запустить на месяц-другой в режиме сбора статистики, а потом проанализировать полученную информацию.