Android SSLServerSocket вызывает увеличение собственной памяти в приложении, OOM

Ответ 1

Я предполагаю, что это будет значительная инвестиция времени, но я вижу, что Valgrind был перенесен на Android. Вы могли бы попробовать его запустить и запустить. Конечно, если вы обнаружите утечку внутренней памяти, вы не можете сделать ничего, кроме как попытаться исправить ошибку в будущих версиях Android.

В качестве обходного решения вы можете сделать свое приложение многопроцессором и поместить службу https в отдельный процесс. Таким образом, вы можете периодически перезапускать его, избегая OOM. Возможно, вам также понадобится третий процесс, который просто принимает подключения к порту 443 и передает их сотруднику https, чтобы избежать крошечных отключений, когда перезагружается рабочий стол https.

Это также звучит как значительная временная инвестиция:) Но это, вероятно, успешно устранит проблему.

--- EDIT: Подробнее ---

Да, если у вас есть основное приложение с собственным пользовательским интерфейсом, рабочий процесс для обработки SSL и рабочий процесс для приема запросов SSL (который, как вы говорите, вероятно, не может быть 443), тогда поверх вашего обычного Классы активности, у вас будет два класса Service, и манифест будет размещать их в отдельных процессах.

Обработка процесса SSL: вместо того, чтобы ожидать, что OOM приведет к сбою службы, служба может контролировать свой собственный Debug.getNativeHeapSize() и явно перезапускать службу, когда она слишком сильно увеличилась. Либо это, либо перезапустите автоматически после каждых 100 запросов или около того.

Обработка процесса прослушивания сокетов. Эта служба просто прослушивает выбранный вами TCP-порт и передает необработанные данные процессу SSL. Этот бит требует некоторой мысли, но наиболее очевидным решением является просто прослушивание SSL-процессов на другом локальном порту X (или переключение между различными портами), и процесс прослушивания сокетов пересылает данные в порт X. Причина для того, чтобы процесс прослушивающего сокета был изящно обработан возможностью того, что X не работает - как это может быть, когда вы его перезагружаете.

Если ваши требования допускают случайные мини-отключения, я бы просто обработал процесс обработки SSL и пропустил процесс прослушивания сокетов, это относительно простое решение - не так уж и отличается от того, что вы делали бы нормально. Это процесс прослушивания сокетов, который усложняет решение...

Ответ 2

Помогает ли это явно закрыть входной поток? В примере кода входной поток кажется закрытым только в случае исключения SocketTimeoutException.

- EDIT -

Вы можете переименовать run() в run2() и переместить цикл while в run() и удалить его из run2() и посмотреть, не изменилось ли это? Это не могло быть решением, но могло бы сказать вам, если какой-либо из долгоживущих объектов освободит память, когда их ссылки будут удалены.

Ответ 3

Есть одна деталь, которую я бы рекомендовал изменить в своей реализации.

Составьте список всех ваших переменных ресурсов, например, Sockets, Streams, Writers и т.д. Обязательно запишите выражение вне вашего оператора try и обязательно сделайте очистку/закрытие в заявлении finally. Я обычно делаю что-то вроде этого, чтобы быть на 100% уверенным:

InputStream in = null;
OutputStream out = null;

try {
    //assign a proper value to in and out, and use them as needed.
} catch(IOException e) {
    //normal error handling
} finally {
    try {
        in.close();
    } catch(IOException e) {}
    try {
        out.close();
    } catch(IOException e) {}
}

Это выглядит немного запутанным, но представьте, что вы используете свой Stream в блоке try, и вы получаете некоторое исключение, тогда ваши потоки никогда не закрываются, и это потенциальная причина утечек памяти.

Я не могу гарантировать, что это причина, но она должна быть хорошей точкой запуска.

Об управлении вашим сервисом. У меня было много неприятностей с услугами Android, потому что я запускал их в том же потоке, что и графический интерфейс. В некоторых случаях Android увидит некоторый код, который выполняется слишком долго и убивает ваш основной процесс, чтобы защитить от сбоев. Решение, которое я нашел, состояло в том, чтобы следовать предложению из этого урока (см. Пункт 4):

http://www.vogella.com/articles/AndroidServices/article.html

После этого моя служба просто работала так, как ожидалось, и не мешала моему графическому интерфейсу.

Привет