|
|
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Никак не могу понять, как защитить GUI приложение от проблем с глобальными сбоями типа OutOfMemory. Хочется чтобы такие сбои не приводили к непредсказуемому поведению приложения (типа застрелов), а просто позволить пользователю дождаться более удачного момента, чтобы выпполнить действие. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. Однако в этом примере после запуска потока, сжирающего память не удается даже нажать на кнопку Release... после минуты усиленной работы GC приложение просто отстреливает JFrame, хотя джава машина продолжает работать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.09.2007, 21:19:59 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
по моему когда прилетает OutOfMemory, тогда уже бесполезно с ней бороться. У тебя JVM захлебнулась и приложению кирдык. Нужно до этого просто не доводить и следить за тем чтобы ненужные объекты становились доступны для gc. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 10:57:36 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
может -Xmx поможет отцу русской демократии, хотя это и не выход но иногда помогает, когда код уже вылизан. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 11:24:04 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
vas0по моему когда прилетает OutOfMemory, тогда уже бесполезно с ней бороться. У тебя JVM захлебнулась и приложению кирдык. Нужно до этого просто не доводить и следить за тем чтобы ненужные объекты становились доступны для gc. Проблема не в ненужных объектах, а в физическом недостатке памяти, который просто нужно временно пережить, не умерев на пути к светлому будущему :) Все-таки ОС, БД, разные сетевые сервисы не стреляются и не умирают при недостатке памяти, а просто временно отказывают в обслуживании, неужели это невозможно для ГУИ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 16:20:16 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Никак. OutOufMemory Error возникает только если нет возможности найти память для объекта после выполнение сборщика мусора. Другими словами, сначала освобождается, что можется, и если после этого не хватает памяти - вызывается ошибка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.09.2007, 16:27:20 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Все зависит от задачи, которую решает приложение. Если перед выполнением задачи возможно достаточно точно оценить, сколько потребуется памяти, то перед выполнением такой задачи можно посмотреть сколько места осталось в куче и если будет видно, что его не хватит для выполнения задачи, то не выполнять ее. Так делает JEdit к примеру, если попытаться им открыть очень большой файл, то он вывидит диалог в котором написано, что операцию выполнить невозможно и ссылка на мануал - как дать приложению больше памяти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 12:23:22 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
1. OOM пролетает в eater thread, поэтому если надо поставить default exception handler, его надо ставить например при создании потока eater. При этом есессно не нужно ловить Throwable (это вообще дурной стиль). 2. Когда случится OOM, eater thread будет в состоянии terminated и вызов interrupted - что мертвому припарка. 3. "приложение просто отстреливает JFrame, хотя джава машина продолжает работать" посмеялсо. RTFM ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 13:05:54 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Timm1. OOM пролетает в eater thread, поэтому если надо поставить default exception handler, его надо ставить например при создании потока eater. При этом есессно не нужно ловить Throwable (это вообще дурной стиль). Вы не поняли как работает код. Eater thread постоянно доедает всю доступную память, поэтому я не хочу чтобы он завершался ни при каких условиях и ловлю Throwable (в т.ч. OutOfMemoryError), поймав который просто уменьшаю интенсивность сжирания памяти. Речь не идет о тоне и пр. сторонах программирования, представлен конкретный код, есть конкретная задача -- заставить его работать так, как он должен (по моему мнению) работать. Timm 2. Когда случится OOM, eater thread будет в состоянии terminated и вызов interrupted - что мертвому припарка. См. п. 1. eater thread никогда не будет в состоянии terminated. Timm 3. "приложение просто отстреливает JFrame, хотя джава машина продолжает работать" посмеялсо. RTFM И кто же интересно вызывает close фрейма и с какого перепугу? Это типа нормальное поведение Swing'а закрывать фреймы когда ему вздумается? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 17:37:58 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
wessenВсе зависит от задачи, которую решает приложение. Если перед выполнением задачи возможно достаточно точно оценить, сколько потребуется памяти, то перед выполнением такой задачи можно посмотреть сколько места осталось в куче и если будет видно, что его не хватит для выполнения задачи, то не выполнять ее. Так делает JEdit к примеру, если попытаться им открыть очень большой файл, то он вывидит диалог в котором написано, что операцию выполнить невозможно и ссылка на мануал - как дать приложению больше памяти. Это было бы вариантом для монолитного приложения, но когда какой-то модуль начинает сжирать память (например из за ошибки программиста или ошибки пользователя -- запустил слишком сложную операцию), то я совершенно не хочу, чтобы данные в других модулях были потеряны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 17:41:20 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Турборуль Timm1. OOM пролетает в eater thread, поэтому если надо поставить default exception handler, его надо ставить например при создании потока eater. При этом есессно не нужно ловить Throwable (это вообще дурной стиль). Вы не поняли как работает код. Это точно. Твой код - memory leak. Выполняется операция, N раз, при этом расходуемая память планомерно растет после каждого выполнения, и не отдается. Выхода из _такой_ ситуации нет ни для обычных, ни для GUI-шных приложений, хоть гиг выдели, хоть два. рано или поздно все умрет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.09.2007, 19:11:16 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Турборуль Это было бы вариантом для монолитного приложения, но когда какой-то модуль начинает сжирать память (например из за ошибки программиста или ошибки пользователя -- запустил слишком сложную операцию), то я совершенно не хочу, чтобы данные в других модулях были потеряны. memory leak это fatal error и никак иначе, такие баги в идеале должны отлавливаться на этапе тестирования и отладки, а ты так рассуждаешь, как-будто это обычное дело. и вообще, если возникает исключение, которое наследуется от Error, то JVM хана, она не в рабочем состоянии, ничего сделать уже нельзя, только restart. почитай вобщем java doc. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.09.2007, 00:48:09 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
wessen Турборуль Это было бы вариантом для монолитного приложения, но когда какой-то модуль начинает сжирать память (например из за ошибки программиста или ошибки пользователя -- запустил слишком сложную операцию), то я совершенно не хочу, чтобы данные в других модулях были потеряны. memory leak это fatal error и никак иначе, такие баги в идеале должны отлавливаться на этапе тестирования и отладки, а ты так рассуждаешь, как-будто это обычное дело. и вообще, если возникает исключение, которое наследуется от Error, то JVM хана, она не в рабочем состоянии, ничего сделать уже нельзя, только restart. почитай вобщем java doc. Т.е. то, что в c/c++ решается кодом Код: plaintext 1. 2. в java решается перезапуском машины? Забавно... Почитал javadoc, но ничего похожего там не нашел. Timm Турборуль Timm1. OOM пролетает в eater thread, поэтому если надо поставить default exception handler, его надо ставить например при создании потока eater. При этом есессно не нужно ловить Throwable (это вообще дурной стиль). Вы не поняли как работает код. Это точно. Твой код - memory leak. Выполняется операция, N раз, при этом расходуемая память планомерно растет после каждого выполнения, и не отдается. Выхода из _такой_ ситуации нет ни для обычных, ни для GUI-шных приложений, хоть гиг выдели, хоть два. рано или поздно все умрет. Зачем так прикапывать к тестовому примеру и вечно уходить с основной темы в сторону memory leak? Ну замените eater thread на следующий. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. Причем поток этот запускается в модуле, о существовании которого другие модули даже не догадываются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 18:07:29 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Турборуль Зачем так прикапывать к тестовому примеру и вечно уходить с основной темы в сторону memory leak? Ну замените eater thread на следующий. Ни в коем случае не ухожу от темы. Пойми, что твой код _расходует память и не освобождает ее_ андестенд? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 18:19:37 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Timm Турборуль Зачем так прикапывать к тестовому примеру и вечно уходить с основной темы в сторону memory leak? Ну замените eater thread на следующий. Ни в коем случае не ухожу от темы. Пойми, что твой код _расходует память и не освобождает ее_ андестенд? Я заменил код на тот, который расходует и освобождает, что изменилось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 19:30:32 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
http://www.devx.com/tips/Tip/5542 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.09.2007, 21:44:45 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Турборуль Timm Турборуль Зачем так прикапывать к тестовому примеру и вечно уходить с основной темы в сторону memory leak? Ну замените eater thread на следующий. Ни в коем случае не ухожу от темы. Пойми, что твой код _расходует память и не освобождает ее_ андестенд? Я заменил код на тот, который расходует и освобождает, что изменилось? В чем проблема в измененном коде eater'a? я ее не вижу. Еще раз: "Хочется чтобы такие сбои не приводили к непредсказуемому поведению приложения " такого поведения в общем случае обеспечить невозможно. Какую то защиту можно организовать, если при старте приложения создать абсолютно все объекты которые понадобятся при обработке OOM и в обработке оперировать только ими. И то не во всех случаях поможет. лучше фиксить проблемы с памятью. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 15:50:00 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Timm В чем проблема в измененном коде eater'a? я ее не вижу. В том, что если выделить достаточно много памяти, свинг застрелит фрейм, если кликнуть по кнопке. Timm Еще раз: "Хочется чтобы такие сбои не приводили к непредсказуемому поведению приложения " такого поведения в общем случае обеспечить невозможно. Какую то защиту можно организовать, если при старте приложения создать абсолютно все объекты которые понадобятся при обработке OOM и в обработке оперировать только ими. И то не во всех случаях поможет. лучше фиксить проблемы с памятью. Ок, тогда может лучше обсудить как реализуют такую защиту реальные приложения? Например, графические оболочки. Я не уверен насчет kde/gnome, так как редко их использовал, но винда точно не начинает закрывать окна при недостатке памяти и уж тем более не застреливает все на своем пути. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 17:45:17 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Leonidvhttp://www.devx.com/tips/Tip/5542 1) это не вариант для многопоточных приложений 2) это не вариант для крупных приложений, не вставлять же такую проверку после каждой инструкции, которая что-то создает? Хочется универсальный удобный механизм типа UncaughtExceptionHandler. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 17:47:26 |
|
||
|
OutOfMemory и прочие неприятности для GUI
|
|||
|---|---|---|---|
|
#18+
Турборуль Timm В чем проблема в измененном коде eater'a? я ее не вижу. В том, что если выделить достаточно много памяти, свинг застрелит фрейм, если кликнуть по кнопке. 1. версия JVM и ОС 2. параметры запуска 3. полностью код который к этому приводит. Я такого не наблюдал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.09.2007, 17:48:12 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=34832947&tid=2144494]: |
0ms |
get settings: |
18ms |
get forum list: |
26ms |
check forum access: |
7ms |
check topic access: |
7ms |
track hit: |
53ms |
get topic data: |
20ms |
get forum data: |
6ms |
get page messages: |
114ms |
get tp. blocked users: |
3ms |
| others: | 375ms |
| total: | 629ms |

| 0 / 0 |
