Java Sun Реализация SSL Пропускает Память?
Это не прямой ответ на Ваш вопрос.
Read, почему массивы считают несколько вредными . Я предложил бы, чтобы Вы возвратили IList< string> в этом случае и реструктурируйте код немного:
IList GetTheStuff() {
List s = new List();
if( somePredicate() ) {
// imagine we load some data or something
}
return s;
}
Таким образом вызывающая сторона не должна заботиться о пустых возвращаемых значениях.
РЕДАКТИРОВАНИЕ : Если возвращенный список не должен быть доступным для редактирования, можно обернуть Список в ReadOnlyCollection. Просто измените последнюю строку на. Я также рассмотрел бы эту лучшую практику.
return new ReadOnlyCollection(s);
4 ответа
Вы видели, что соединение закрывается. Скорее всего, это еще как-то открыто. 1Мб - это просто лишняя тема. Однако я не уверен, в чем именно будет причина.
Все SSL-соединения связаны с SSL-сеансом, который можно повторно использовать для разных TCP-соединений для уменьшения накладных расходов на рукопожатие при согласовании временных ключей шифрования после установления фактического TCP-соединения. Возможно, ваши клиенты каким-то образом принудительно создают новый сеанс, и поскольку конфигурация по умолчанию для Java 6, похоже, предусматривает кеширование неограниченного количества сеансов в течение одного часа, вы легко можете столкнуться с проблемой памяти.
Вы может управлять этими настройками для вашего серверного сокета, получая SSLSessionContext из вашего серверного сокета с помощью getSession (). getSessionContext () и установите размер кеша с помощью setSessionCacheSize и тайм-аут (в секундах) с помощью setSessionTimeout. Я ожидал, что можно будет изменить конфигурацию по умолчанию через системные свойства, но я не могу найти никакой документации по этому поводу. Возможно, вы сможете найти что-то самостоятельно, погуглив немного дольше, чем я.
Вы уверены, что устанавливаете лимит на правильный контекст сеанса? Я ошибался, говоря, что контекст доступен из серверного сокета. Вы должны установить его через SSLContext перед созданием серверного сокета:
SSLContext sslContext = SSLContext.getDefault();
sslContext.getServerSessionContext().setSessionCacheSize(1000);
SSLServerSocket ss = (SSLServerSocket)
sslContext.getServerSocketFactory().createServerSocket(<port>);
Без этого ограничения было бы легко воспроизвести вашу «утечку» памяти, поскольку каждый кешированный сеанс SSL позволяет использовать где-то около 7-800 байт кучи. С ограничением количества сеансов,
1 МБ - это память, необходимая для создания потока, дополнительного или нет.
Есть ли какие-либо записи в списке ошибок для этого класса или пакета? Первым шагом будет его проверка.
Второй шаг - предположить, что проблема заключается в вашем коде, а не в материалах Sun. Это более вероятно, просто потому, что часто используемый класс в Java JDK используется пользователями во всем мире. Если бы произошла ошибка, она бы уже обнаружилась.
Это не означает, что код JDK не содержит ошибок, просто вы должны сначала заподозрить свой код.
Получите профилировщик и измерьте. Не угадайте.
не про Солнце. Это более вероятно, просто потому, что часто используемый класс в Java JDK используется пользователями во всем мире. Если бы произошла ошибка, она бы уже обнаружилась.Это не означает, что код JDK не содержит ошибок, просто вы должны сначала заподозрить свой код.
Получите профилировщик и измерьте. Не угадайте.
не про Солнце. Это более вероятно, просто потому, что часто используемый класс в Java JDK был раскритикован пользователями во всем мире. Если бы произошла ошибка, она бы уже обнаружилась.Это не означает, что код JDK не содержит ошибок, просто вы должны сначала заподозрить свой код.
Получите профилировщик и измерьте. Не угадайте.
На каком оборудовании вы работаете? Можете ли вы выполнить netstat и проверить состояние ваших подключений?
Я провел нагрузочное тестирование Tomcat и без проблем достиг 500 новых запросов SSL в секунду, выполняемых часами, с кучей 1 ГБ в Solaris. Кроме того, вы можете отслеживать количество потоков, выполняемых в контейнере.