Что делает горячее развертывание “тяжелой проблемой”?
with open('document.csv','a') as fd:
fd.write(myCsvRow)
Открытие файла с параметром 'a' позволяет добавлять к концу файла вместо простой перезаписи существующего содержимого. Попробуйте это.
4 ответа
Когда класс загружается, различные статические данные о классе хранятся в PermGen. Пока живая ссылка на этот Экземпляр класса существует, экземпляр класса не может быть собран "мусор".
я полагаю, что часть проблемы имеет отношение, должен ли GC удалить старые Экземпляры класса от генерала перманента, или нет. Как правило, каждый раз, когда Вы горячий развертываетесь, новые экземпляры класса добавляются к пулу памяти PermGen, и старые, теперь неиспользованные, обычно не удаляются. По умолчанию JVMs Sun не выполнит сборку "мусора" в PermGen, но это может быть включено с дополнительными аргументами команды "Java".
Поэтому, если Вы горячий развертываетесь достаточно раз, Вы в конечном счете исчерпаете свое пространство PermGen.
, Если Ваше веб-приложение не закрывается полностью при неразвертывании - если оно оставляет выполнение Потока, например - тогда, все Экземпляры класса, используемые тем веб-приложением, будут прикреплены в пространстве PermGen. Вы повторно развертываете и теперь имеете другую целую копию всех этих Экземпляров класса, загруженных в PermGen. Вы не развертываетесь, и Поток продолжает идти, прикрепляя ДРУГОЙ набор экземпляров класса в PermGen. Вы повторно развертываете и загружаете целый сетевой набор копий..., и в конечном счете Ваш PermGen заполняется.
можно иногда фиксировать это:
- аргументы команды Предоставления к недавней JVM Sun для включения GC в PermGen и классов. Это:
-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled -XX:+CMSPermGenSweepingEnabled - Используя другую JVM, которая не нанимает фиксированный размерный PermGen или это делает GC на загруженных классах
, Но это поможет только [1 120], если Ваше веб-приложение закроется полностью и чисто, не оставляя живые ссылки ни на один из Экземпляров класса никакого Класса загруженными загрузчиками Класса для того веб-приложения.
Даже это не обязательно решит проблему, из-за утечек загрузчика класса. (А также слишком много интернированных строк в некоторых случаях.)
Выезд следующие ссылки для больше (два полужирных имеют хорошие схемы для иллюстрирования части проблемы).
Проблемой в общих чертах является модель обеспечения безопасности Java, который на самом деле пытается предотвратить это класс, который был уже загружен быть загруженным снова.
, Конечно, Java с начала поддерживал динамическую загрузку класса, что это трудно, перезагрузка класса.
Это было, считают вредными (и на серьезном основании), что под управлением JAVA-приложение было введено с новым классом с вредоносным кодом. Например, java.lang. Представьте в виде строки взломанную реализацию, прибывающую из Интернета, что вместо того, чтобы создать строку, удаляет некоторый случайный файл hile вызов длины метода ().
Так, они способ, которым был задуман Java (и я предполагаю CLR.NET в последствии, потому что это было высоко "вдохновлено" в JVM) состоял в том, чтобы предотвратить уже загруженный класс для загрузки снова того же самого VM.
Они предложили механизм для переопределения этой "функции". Classloaders, но снова правила для загрузчиков класса были, они должны спросить разрешение к "родителю" classloader прежде, чем попытаться загрузить новый класс, если родитель уже загрузил класс, новый класс проигнорирован.
, Например, я использовал classloaders, которые загружают классы из LDAP или RDBMS
, который развертывают горячие, становится необходимостью в мире Java, когда сервер приложений стал господствующей тенденцией для EE Java (и также создайте потребность в микро контейнерах как пружина для предотвращения подобных нагрузка).
Перезапуск целого сервера приложений после того, как каждая компиляция сводит любого с ума.
Так поставщик сервера приложений, предложите этому "пользовательскому" классу загрузчики для помощи горячему развертыванию, и использование конфигурационного файла, того поведения, ДОЛЖНО быть отключено, когда установлено в производстве. Но компромисс - Вы, должны использовать тонны памяти в разработке. Так хороший способ сделать это - перезапуск каждые 3 - 4 развертывания.
Этого не происходит с другими языками, которые были разработаны с начала загрузить их классы.
В Ruby, например, можно даже добавить методы к рабочему классу, переопределить метод во времени выполнения или даже добавить отдельный метод для уникального конкретного объекта.
компромисс в этих видах сред является, конечно, памятью и скоростью.
я надеюсь, что это помогает.
РЕДАКТИРОВАНИЕ
я нашел этот продукт некоторое время назад, который обещает, что перезагрузка, делают максимально простыми. Я не помнил ссылку, когда я сначала записал этот ответ, и я делаю.
JVM Sun сделала, чтобы PermGen расположил с интервалами зафиксированный, и в конечном счете это все использовало (да, по-видимому из-за ошибки в classloader-связанном коде) => OOM.
, Если можно использовать JVM другого поставщика (например, Weblogic один), он динамично расширяет пространство PermGen, таким образом, Вы никогда не будете получать permgen-связанный OOM.
Какую версию Java Вы используете? Были ошибки в раннем Sun 1.4.2, но он работал в течение долгого долгого времени.
BTW, как Вы сообщите новости своему руководителю группы? Действительно ли Вы - руководитель группы?