|
|
|
Как обработать потенциальную нехватку памяти?
|
|||
|---|---|---|---|
|
#18+
1. Самый неправильный пример это такой : Код: java 1. 2. 3. http://habrahabr.ru/post/169883/ на weak - можно построить кеш - ( как WeakHashMap) Array[] - в котором будут не ссылки на объекты а weak ссылки ,в которых будут ссылки на ваши объекты - тогда объекты могут быть уничтожены ... и wr.get() = вернет null. http://javarevisited.blogspot.ru/2014/03/difference-between-weakreference-vs-softreference-phantom-strong-reference-java.html 2. заменить разбор в памяти и перенести его в файлы ... будем много работы с диском, но так работают во всех конторах где есть задачи разбора больших файлов ... (логи, видео потоки итд ...) + либы типа Hadoop for Data Analytics , Hadoop MapReduce итд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 17:11 |
|
||
|
Как обработать потенциальную нехватку памяти?
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev... 1. Нормальный алгоритм. Где требования к ресурсам не связаны (слабо связаны) с размером файла. 2. Если корреляция есть - ограничение на размер обрабатываемого файла 3. Если хочется полностью независимости по памяти - запускать дочернею JVM. В принципе и я о том же, но вопрос был о программе парсящей файлы, собсно и ответил что если памяти недают попробовать жрать поменьше если меньше жрать нельзя матюкнутся и откатиться все ж лучше чем по оутофмемори вылететь с непонятным состоянием. Если обработать нельзя постараться предотвратить... Собственно это очевидные вещи же. Имхо дальнейшее обсуждение имеет смысл уже с уходом в предметную область что именно и как делается ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 17:36 |
|
||
|
Как обработать потенциальную нехватку памяти?
|
|||
|---|---|---|---|
|
#18+
redwhite902. Совсем плохая ситуация, если программа свалилась, перед этим правда часть распарсила, пользователь видит результат(частичный), смотрит, что выполнение закончилось и думает, что всё уже успешно закончилось. Как такое предотвратить? catch(Throwable) ? В идеале твой парсер должен быть - finite state machine . Это предполагает фиксированную память на его тело при бесконечном разнообразии входных файлов. Эту память можно умножить на количество экземпляров паралельных потоков если таковые будут. При благоприятном стечении обстоятельств такой парсер проработает долгие годы пока не упадёт железо или ОС на сервере. В некоторых параноидальных вариантах отказоустойчивости ты можешь запускать 2 java процесса( по аналогии со средой разработки Idea, которая запускает другие экземпляры компилляций как отдельные процессы). Первый будет хозяином (master-process). Он будет запускать парсеры и контролировать факт их успешного завершения. Как контролировать - это ты сам решишь. К примеру парсер после завершения может переименовывать файлы в *.$$$ как признак. Главное чтоб фиксация была атомарной с точки зрения диска. Для долго-играющих процессов можно ввести Watchdog timer, или Hearbit как признак того что процесс еще жив. И убивать его в случае тишины или неответа в заданный период. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 18:19 |
|
||
|
Как обработать потенциальную нехватку памяти?
|
|||
|---|---|---|---|
|
#18+
1. надо подсунуть парсеру данные, которые нагрузят его сильнее, чем реальные данные, и посмотреть как он будет работать. 2. если одного потока гарантированно хвататет, то можно при ооme останавливать парсящий поток и оставлять эту часть работы в очереди - для обработки другими потоками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.06.2014, 23:43 |
|
||
|
|

start [/forum/topic.php?fid=59&msg=38678753&tid=2127001]: |
0ms |
get settings: |
10ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
73ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 237ms |
| total: | 425ms |

| 0 / 0 |
