Ответ 1
Объект привязки?:
Позвольте сначала понять Pinning Object. В принципе, Pinning - это re, мы временно помещаем объект в кучу, чтобы сборщик мусора не пытался перемещать объект, пока мы не удалим тег. Обычно объект может перемещаться с одного адреса на другой, если он продвигается (т.е. перемещается из молодого пространства в прежнее пространство) или как часть уплотнения (дефрагментация). Но если объект закреплен, 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 также могут оказаться полезными.
Решения:
Если вы найдете правильную причину, вы можете написать правильную обработку исключений и, конечно же, закрыть FileInputStream, когда мы закончим с ней, чтобы избежать нежелательного переполнения.