| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > Java Non-Heap Usage |
| Автор: sith 4.11.2011, 21:56 |
| всем привет. недавно узнал что есть такая штука как Java non-heap memory. Кто то когда то сталкивался с использованием этой области памяти. Как туда что то ложить и вытягивать. может есть какието доки по этому поводу??? |
| Автор: Stolzen 5.11.2011, 07:50 |
| Non-heap? Полагаю, что речь идет о PermGen - области памяти, в которой хранится метадата о всех загруженных классах + кое что еще. http://stackoverflow.com/questions/2129044/java-heap-terminology-young-old-and-permanent-generations можно почитать о поколениях в памяти jvm (там речь о HotSpot) и о том, как это влияет на сборку мусора. |
| Автор: sith 5.11.2011, 09:59 |
| не совсем... я слышал об этом из разговора нескольких програмистов ... и скажем так лишь краем уха... речь шла о том что в джаве можно использовать некую non-heap память. в целях кеширования своих обьектов. возможно это и она и есть... но мне нужна информация как туда что то писать и читать... |
| Автор: Stolzen 5.11.2011, 12:03 | ||
Например строки, которые кешируются с помощью метода intern(), идут в PermGen. Возможно (не уверен) статические перменные тоже живут в пермгене - но я так понимаю, в спецификации это точно не обозначено, реализация зависит от вендора. Ведь проблема в том, что статические перменные можно переназначить, значит будут появлятся объекты, которые нужно собрать сборщиком. А это вряд ли хорошо для пермгена. |
| Автор: sith 5.11.2011, 12:21 |
| мне было итересно все таки... если есть non-heap память... могу ли я с ней работать, ложить и четать от туда обьекты... естественно сам забочась о сборке мусора |
| Автор: Stolzen 5.11.2011, 12:26 | ||
А можно поинтересоваться, для какой цели это нужно?
Как это? |
| Автор: sith 5.11.2011, 12:50 |
 хм... точно еще не знаю... |
| Автор: Skynin 5.11.2011, 13:22 |
| PermGen тоже подпадает под работу сборщика мусора если указать опции. Наверное имелась ввиду память выделяемая средствами ОСи а не JVM. Выделение и работа с такой памятью осуществляется написанием бинарного кода, платформозависимого кода и работой с ним через JNI/JNA Применяется в высоконагруженных системах, и возможно реализован в серьезных фреймвораках кэширования. |
| Автор: COVD 5.11.2011, 18:24 | ||
http://www.terracotta.org/products/bigmemory ?
|
| Автор: Skynin 5.11.2011, 19:24 |
| Аха, и сам не знал: BigMemory achieves off-heap storage using Direct ByteBuffers, which is a feature introduced with NIO in Java 1.4 to allow zero copy buffers between Java applications and the operating system as it's not possible with memory belonging to Java heap because of unstable location http://www.quora.com/How-does-BigMemory-hide-objects-from-the-Java-garbage-collector Direct buffers NIO supports a type of ByteBuffer usually known as a direct buffer. Direct buffers can essentially be used like any other ByteBuffer (and are implemented as a ByteBuffer subclass), but have the property that their underlying memory is allocated outside the Java heap. More specifically, direct buffers have the following properties: once allocated, their memory address is fixed for the lifetime of the buffer; because their address is fixed, the kernel can safely access them directly and hence direct buffers can be used more efficiently in I/O operations; in some cases, accessing them from Java can be more efficient (there's potentially less overhead in looking up the memory address and/or other housekeeping required before accessing a Java object)— see the example NIO buffer performance measurements made in Hotspot under Windows; via the Java Native Interface, you can actually set the address arbitrarily if required (e.g. to access hardware at a particular address, or to perform the allocation yourself). In practice, in current versions of Hotspot, the memory is allocated via a malloc(), although this could vary in other VMs or in a future version of Hotspot. http://www.javamex.com/tutorials/io/nio_buffer_direct.shtml |
| Автор: sith 5.11.2011, 21:18 |
| поидеи это оно... типа с этим ByteBuffer можно складывать байт масивы в не хипа |
| Автор: Stolzen 7.11.2011, 06:50 |
| А как память чистить? Или все утекать будет? Вообще да, занятная штука. |
| Автор: Skipy 7.11.2011, 12:18 |
| Память собирается точно так же, как и обычная. В смысле, собирается объект типа ByteBuffer, и при этом в нем происходит сбор памяти. На самом деле там достаточно прозрачно всё сделано - память выделяется через Unsafe прямо в java-коде, создается обработчик, ее собирающий, и всё это кладется через PhantomReference в очередь. При сборке запускается обработчик и собирает память. Весь этот код доступен в исходниках по лицензии JRL, да и обычного src.zip хватит, чтобы разобраться, правда, без деталей. Так что если грамотно всё организовать и не прикапывать жесткие ссылки - всё соберется. В Wicket 1.3.4 была такая утечка, потом поправили. Вообще держать данные вне хипа - плохая практика. Эта память собирается сильно сложнее и дольше, а необходимость вылезти за хип чаще всего говорит о том, что в приложении проблемы. За хипом память тоже не беспредельная. Предназначение прямого выделения - операции ввода-вывода. Выделенные в ОС буферы памяти могут сильно ускорить обмен с устройствами, ибо ОС будет с ними работать напрямую. А потом и нам можно напрямую, что тоже быстро. |
| Автор: Galaran 7.11.2011, 23:45 |
| http://habrahabr.ru/blogs/java/131017/ Там ещё внизу поста есть ссылка на блог автора, тоже посоветую глянуть |
| Автор: COVD 8.11.2011, 03:22 | ||||
 Из "Интересная статья на хабре на эту тему":
Не подойдет для клиентского приложения. А для серверной системы в том, наверное, и состоит искусство разработчика, чтобы система получилась "слабо связанна" и "хорошо делилась логически". |
