| 1.1, Аноним (-), 00:29, 15/01/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
"Добавлены специальные средства для анализа распределения памяти и выявления утечек памяти;"
И скажите, пожалуйста, куда подевался знаменитый GC?
| | |
| |
| 2.2, iZEN (ok), 01:12, 15/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
 Сюрприз: утечки памяти случаются и в Java-программах из-за потери программистом контроля над создаваемыми объектами. Но это не пробой стека и не переполнение буфера, как в программах на C/C++. ;)
| | |
| |
| 3.4, Аноним (-), 01:50, 15/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
попросту говоря
- создаётся неограниченное колличество обьектов ...
| | |
| |
| |
| 5.8, VoDA (ok), 13:26, 15/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
 Создаются и сохраняются в виде доступном для работающих тредов.
За удалением следит GC и он грохнет при возможности.
| | |
|
|
|
| 2.3, Аноним (-), 01:46, 15/01/2011 [^] [^^] [^^^] [ответить]
| +/– | |
я сам удивился когда давно увидел про "утечку памяти" в java
а знакомый когда прочитал это и я сказал что это на самом деле
сказал
- Чё за х... такую ху... назвать утечкой памяти
| | |
| |
| 3.5, Ярослав (??), 02:14, 15/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Не могу не согласиться.
Как-то возникла проблема. При детальном изучении то-ли Tomcat4, то-ли Tomcat5 выяснил, что после загрузки класса с jsp-страницей, этот класс никогда не выгружается. Может только перегружаться, если страница была изменена. Думал, ошибка или недоработка. Предложил свою заплатку, или как минимум, заострить внимание на проблеме. На что мне ответили, что об этом всем [разработчикам?] и так известно, что это, вроде как, и не плохо [а даже вовсе наоборот], и вообще - памяти для серверов жалеть не надо.
А финальный тест был простой - сказать Tomcat, чтобы он html как jsp обрабатывал, добавить в качестве web-приложения документацию к jdk, и wget...
С того самого момента использую resin. Выводы о Tomcat сделал соответствующие.
| | |
| |
| 4.7, NaN (?), 11:05, 15/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
В том и дело что это Application Server и приложения живут в нем долго до тех пор когда их нужно будет перегрузить.
| | |
| |
| 5.11, Ярослав (??), 02:10, 17/01/2011 [^] [^^] [^^^] [ответить]
| +/– |
> В том и дело что это Application Server и приложения живут в
> нем долго до тех пор когда их нужно будет перегрузить.
Одна тонкость. Сарвлет не является приложением. Про автоматическую выгрузку веб-приложений по желанию контейнера речи не идёт.
| | |
|
| 4.9, VoDA (ok), 13:28, 15/01/2011 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> что после загрузки класса с jsp-страницей, этот класс никогда не выгружается. Может только перегружаться, если страница была изменена. Думал, ошибка или недоработка.
а почему это ошибка? или в чем не доработка?
| | |
| |
| 5.10, Ярослав (??), 02:05, 17/01/2011 [^] [^^] [^^^] [ответить]
| +/– | |
VoDA,
Почему [я] _думал_, что это ошибка или недоработка? Потому что достаточно простые действия, приводили к результату, который [меня] удивлял.
Да, действительно, решение о том, когда выгружать загруженный класс сервлета, спецификация оставляет непосредственно за имплементацией сервлет-контейнера.
Да, действительно, _никогда_ не выгружать загруженный класс сервлета - это решение, входящее в множество допустимых.
Так что формально, фактически, согласно спецификации, как угодно, это не ошибка и не недоработка.
Для поставленной задачи, однако, это решение, мягко говоря, не являлось приемлемым. Поэтому, собственно, и был выбран другой сервлет-контейнер, мысли разработчиков которого и мои были сонаправлены.
Но это так сказать, объективно. А субъективно - мне больше нравится сервлет-контейнер, который, всё-таки, умеет выгружать сервлеты, а не складирует их в памяти, пока либо сервлеты не кончатся, либо память.
| | |
|
|
|
|
|
