Представлен (http://www.mail-archive.com/announce@tomcat.apache.org/...) релиз Apache Tomcat 7.0.6 (http://tomcat.apache.org/), контейнера для выполнения JSP-страниц и Java-сервлетов с реализацией полной поддержки спецификации Java Servlet 3.0. По приблизительным оценкам Tomcat используется на 75% сайтов, базирующихся на Java. Tomcat 7 позволяет упростить разработку и развертывание сложных web-приложений на языке Java, предоставляя встроенную поддержку возможностей, которые без Tomcat необходимо было бы реализовывать вручную.
Версия 7.0.6 является первым стабильным выпуском в ветке Tomcat 7, прошлые выпуски Tomcat 7.0.x имели статус бета-версий. Из изменений отмечено проведение работы по улучшению производительности в системе управления сессиями, подготовлен новый бинарный вариант поставки для встраивания Tomcat в другие приложения, улучшена работа кода по обнаружению утечек памяти и выявлению ошибок.Из наиболее значительных новшеств (http://tomcat.apache.org/tomc...
URL: http://www.mail-archive.com/announce@tomcat.apache.org/...
Новость: http://www.opennet.me/opennews/art.shtml?num=29278
"Добавлены специальные средства для анализа распределения памяти и выявления утечек памяти;"
И скажите, пожалуйста, куда подевался знаменитый GC?
Сюрприз: утечки памяти случаются и в Java-программах из-за потери программистом контроля над создаваемыми объектами. Но это не пробой стека и не переполнение буфера, как в программах на C/C++. ;)
попросту говоря
- создаётся неограниченное колличество обьектов ...
создаются и не удаляются
Создаются и сохраняются в виде доступном для работающих тредов.За удалением следит GC и он грохнет при возможности.
я сам удивился когда давно увидел про "утечку памяти" в javaа знакомый когда прочитал это и я сказал что это на самом деле
сказал
- Чё за х... такую ху... назвать утечкой памяти
Не могу не согласиться.Как-то возникла проблема. При детальном изучении то-ли Tomcat4, то-ли Tomcat5 выяснил, что после загрузки класса с jsp-страницей, этот класс никогда не выгружается. Может только перегружаться, если страница была изменена. Думал, ошибка или недоработка. Предложил свою заплатку, или как минимум, заострить внимание на проблеме. На что мне ответили, что об этом всем [разработчикам?] и так известно, что это, вроде как, и не плохо [а даже вовсе наоборот], и вообще - памяти для серверов жалеть не надо.
А финальный тест был простой - сказать Tomcat, чтобы он html как jsp обрабатывал, добавить в качестве web-приложения документацию к jdk, и wget...
С того самого момента использую resin. Выводы о Tomcat сделал соответствующие.
В том и дело что это Application Server и приложения живут в нем долго до тех пор когда их нужно будет перегрузить.
> В том и дело что это Application Server и приложения живут в
> нем долго до тех пор когда их нужно будет перегрузить.Одна тонкость. Сарвлет не является приложением. Про автоматическую выгрузку веб-приложений по желанию контейнера речи не идёт.
> что после загрузки класса с jsp-страницей, этот класс никогда не выгружается. Может только перегружаться, если страница была изменена. Думал, ошибка или недоработка.а почему это ошибка? или в чем не доработка?
VoDA,Почему [я] _думал_, что это ошибка или недоработка? Потому что достаточно простые действия, приводили к результату, который [меня] удивлял.
Да, действительно, решение о том, когда выгружать загруженный класс сервлета, спецификация оставляет непосредственно за имплементацией сервлет-контейнера.
Да, действительно, _никогда_ не выгружать загруженный класс сервлета - это решение, входящее в множество допустимых.
Так что формально, фактически, согласно спецификации, как угодно, это не ошибка и не недоработка.
Для поставленной задачи, однако, это решение, мягко говоря, не являлось приемлемым. Поэтому, собственно, и был выбран другой сервлет-контейнер, мысли разработчиков которого и мои были сонаправлены.
Но это так сказать, объективно. А субъективно - мне больше нравится сервлет-контейнер, который, всё-таки, умеет выгружать сервлеты, а не складирует их в памяти, пока либо сервлеты не кончатся, либо память.