Почему JVM не загружает классы из базы данных?

Question

Почему виртуальная машина Java не загружает классы из базы данных (аналогично GAC .NET)? Насколько я понимаю, в настоящее время он должен читать и сканировать манифесты каждого JAR на пути к классам, чтобы найти файлы классов. Разве использование базы данных (например, SQLite) не увеличит время запуска?

Answer 1

Это не потому, что никто не добавил это в стандартные библиотеки. Также для целей начальной загрузки (например, загрузка драйвера JDBC для доступа к БД) все еще должны присутствовать существующие механизмы.

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

Answer 2

Идет очень активная работа по увеличению времени запуска (это одна из целей Project Jigsaw, которая является частью JDK 8).

Но оптимизация не так проста, как просто "сбросить файлы классов в БД".Здесь есть несколько проблем, некоторые из которых конкурируют.

И у GAC есть свои проблемы, которые, я думаю, мы бы не хотели копировать ...

Answer 3

Ваш фундаментальный тезис верен: в загрузке классов Java есть возможности оптимизации, и, очевидно, много работы дублируется в поиске классов, особенно тех, которые часто используются.Производители JVM уже проделали немалую работу в этой области.См. Общее описание данных Oracle для примера.

Я предполагаю, что издержки и сложности использования базы данных являются излишними для решения простой проблемы кэширования и индексации.

Answer 4

В зависимости от того, как вы определяете «базу данных», у IBM ( общие классы ) и Oracle ( общие данные ) уже есть технологии, позволяющие ускорить запуск и уменьшить объем используемой памяти.

Время загрузки класса на самом деле очень мало (для каждого класса в отдельности), поэтому добавление чего-либо вроде базы данных таким образом не приведет к реалистичному изменению вашей производительности, особенно если вам нужно перебить байтыпровод (вместо того, чтобы просто прочитать запись jar локальной файловой системы).Все JVM сегодня сильно оптимизированы по пути загрузки классов, и добавление SQL, безусловно, не повлияет на производительность.(гибкость распределенных репозиториев и т. д. - это другой вопрос, и я вижу в этом преимущества.)

Answer 5

Вы можете создать индексный jar, который сообщит среде выполнения, в каком классе находится jar.Для этого вы берете основной jar приложений и убедитесь, что атрибут Class-Path правильно установлен в Manifest.Затем вы запускаете «jar -i MyMainJar.jar» для создания индекса.

Если у вас нет основного фляги, вы можете создать тот, который просто содержит манифест с установленным атрибутом Class-Path и индекстот.Если вы сначала загрузите этот jar-файл, ClassLoader будет использовать индекс и быстрее находить классы.

Answer 6

Вы можете использовать сервер Nexus в качестве хранилища maven для библиотек и загружать их в контейнер OSGi. Это позволяет вам создавать / развертывать / загружать / выгружать целые библиотеки, не касаясь непосредственно jar-файлов или классов. Тем не менее, он помещает локальные копии библиотек на диск для повышения производительности и не позволяет управлять отдельными классами.

Мне было бы трудно поверить, что загрузка предложений по соединению через сокет происходит быстрее, чем загрузка сжатых файлов непосредственно с диска. (как это делает maven / OSGi) esp. как только файл находится в кеше. Большая часть времени, затрачиваемого на загрузку классов, приходится на код, выполняемый в статических блоках, а затем на компиляцию кода, с которой база данных вам не поможет.

Мне было бы интересно увидеть сравнение производительности. Как репозитории классов баз данных обрабатывают версии? Насколько просто / надежно откатить версию библиотеки, например, или группу классов с взаимозависимостями?