Исключение переполнения исключенного объекта?

Question

Ошибка ниже в журналах. Я не вижу никакого видимого влияния этого на моем приложении , как на пользовательский интерфейс или производительность. Использование weblogic Jrockit JVM.

Caused by: java.lang.InternalError: pinned object overflow! 
    at java.util.zip.Inflater.inflateBytes(Inflater.java:381) ~[na:1.6.0_31] 
    at java.util.zip.Inflater.inflate(Inflater.java:231) ~[na:1.6.0_31] 
    at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:135) ~[na:1.6.0_31] 
    at java.io.FilterInputStream.read(FilterInputStream.java:116) ~[na:1.6.0_31] 
    at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) ~[na:1.6.0_31] 

В сети я не нашел ничего конкретного для pinned object overflow исключения. Для меня это не похоже на проблему программирования, но проблема связана с weblogic или jrockit?

Любые указатели, как я могу избавиться от этого?

Answer 1

Закрепление объекта ?:

Пусть сначала понять пиннингу Object.Basically, Закрепление является Whe повторно мы временно маркировать объект в куче, так что сборщик мусора не будет пытаться не перемещать объект до тех пор, мы удаляем тег. Обычно объект может перемещаться с одного адреса на другой, если он продвигается (т. Е. Перемещается из молодого пространства в прежнее пространство) или как часть уплотнения (дефрагментация). Но если объект закреплен, GC не будет пытаться переместить его, пока он не будет закреплен.

Так почему мы хотим привязать объект?.

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

Если бы мы не смогли вывести буфер, нам нужно было бы выделить дополнительную собственную (вне кучи) память, чтобы перейти к собственному вызову ввода-вывода ОС, а также скопировать данные между кучкой и кучей буферы.

Таким образом, привязывая буфер к постоянному адресу в куче, мы избегаем как того, чтобы сделать ненужное выделенное выделение памяти, так и копию.

Когда может возникнуть переполнение объекта?

Этот сценарий может произойти во время вызова JNI или обработки неправильных исключений в вызовах ввода/вывода. Чтобы узнать реальный факт, нам нужно проанализировать дамп потока, чтобы узнать, сколько потоков заблокировано, т.е. stucked.

Устранение:

Так что вы должны делать, когда у вас есть поток, который появляется застрял в вызове readBytesPinned или writeBytesPinned? Это полностью зависит от того, где приложение пытается считывать данные или записывать данные.

Давайте посмотрим на реальном примере нити застрял делает блокировку чтения:

"ExecuteThread: '2' for queue: 'weblogic.kernel.Default'" id=20 idx=0x2e tid=16946 prio=5 alive, in native, daemon 
     at jrockit/net/SocketNativeIO.readBytesPinned(I[BIII)I(Native Method) 
     at jrockit/net/SocketNativeIO.socketRead(Ljava/io/FileDescriptor;[BIII)I(Unknown Source)[inlined] 
     at java/net/SocketInputStream.socketRead0(Ljava/io/FileDescriptor;[BIII)I(Unknown Source)[inlined] 
     at java/net/SocketInputStream.read([BII)I(SocketInputStream.java:113)[optimized] 
     at oracle/net/ns/Packet.receive()V(Unknown Source)[inlined] 
     at oracle/net/ns/DataPacket.receive()V(Unknown Source)[optimized] 
     at oracle/net/ns/NetInputStream.getNextPacket()V(Unknown Source)[optimized] 
     at oracle/net/ns/NetInputStream.read([BII)I(Unknown Source)[inlined] 
     at oracle/net/ns/NetInputStream.read([B)I(Unknown Source)[inlined] 
     at oracle/net/ns/NetInputStream.read()I(Unknown Source)[optimized] 
     at oracle/jdbc/driver/T4CMAREngine.unmarshalUB1()S(T4CMAREngine.java:1099)[optimized] 
<rest of stack omited> 

В приведенном выше случае, вы можете сказать, из трассировки стека, что (база данных) драйвер JDBC делает блокировка чтения из сетевого сокета. Таким образом, типичным следующим шагом было бы увидеть, есть ли причина, по которой ожидаемые данные могут быть отложены (или даже никогда не приходят вообще).Например, сервер базы данных, с которым мы разговариваем, можно повесить, может возникнуть проблема с сетью, которая задерживает (или даже отбрасывает) ответ базы данных, или может быть какое-то несоответствие протокола, когда обе стороны считают, что это другая сторона повернитесь к разговору. Анализ файлов журналов с обеих сторон может дать информацию о том, что произошло. Если проблема воспроизводима, сбор сетевой трассы и ее анализ с помощью инструмента, такого как WireShark, также могут оказаться полезными.

Решение:

AFER найти правильную причину, вы могли бы написать надлежащую обработку исключений и, конечно, закрыть FileInputStream, когда мы закончили с этим, чтобы избежать нежелательного переполнения.

Ссылки: thread_stuck_at_readbytespinned_writebytespinned