Что такое нативные методы их плюсы и минусы java

Ключевое слово и методы Java Native

Изучите основы собственных ключевых слов и методов Java.

1. Обзор

В этом кратком руководстве мы обсудим концепцию ключевого слова native в Java, а также покажем, как интегрировать методы native в код Java.

2. Ключевое слово native в Java

Прежде всего, давайте обсудим, что такое ключевое слово native в Java.

Он указывает на зависящую от платформы реализацию метода или кода, а также действует как интерфейс между JNI и другими языками программирования.

3. собственные методы

A родной метод-это метод Java (либо метод экземпляра, либо метод класса), реализация которого также написана на другом языке программирования, таком как C/C++.

Мы можем использовать их для:

4. Примеры

Теперь давайте продемонстрируем, как интегрировать эти методы в наш Java-код.

4.1. Доступ к машинному коду на Java

Чтобы загрузить его, мы будем использовать System.LoadLibrary.

4.2. Тестирование собственных методов

Наконец, давайте посмотрим, как мы можем протестировать собственные методы, определенные в классе DateTimeUtils :

Ниже приведен вывод регистратора:

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

5. Заключение

В этой статье мы изучили основы native ключевых слов и методов. На коротком примере мы также узнали, как интегрировать их в Java.

Источник

Что такое нативные методы в Java и где их следует использовать? [Дубликат]

На этот вопрос уже есть ответ здесь:

Нативный метод имеет тот же синтаксис, что и абстрактный метод, но где он реализован?

5 ответов

Что такое нативные методы в Java и где их следует использовать?

Как только вы видите небольшой пример, становится ясно:

Main.java

main.c

Скомпилируйте и запустите :

Выход

Протестировано в Ubuntu 14.04 с Oracle JDK 1.8.0_45.

Итак, ясно, что это позволяет:

Это может быть использовано для:

с компромиссом более низкой мобильности.

Вы также можете вызывать Java из C, но вы должны сначала создать JVM в C: Как вызывать функции Java из C ++?

Метод реализован в «родном» коде. То есть код, который не запускается в JVM. Обычно он написан на C или C ++.

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

Мне нравится знать, где мы используем родные методы

В идеале, совсем нет. На самом деле некоторые функции недоступны в Java, и вам нужно вызывать код на C.

Методы реализованы в коде C.

Необходимость собственного кода Java:

надеюсь, что эти пункты ответят на ваш вопрос:)

Нативные методы позволяют вам использовать код из других языков, таких как C или C ++, в вашем Java-коде. Вы используете их, когда Java не предоставляет необходимую вам функциональность. Например, если бы я писал программу для вычисления какого-либо уравнения и построения его линейного графика, я бы использовал java, потому что это язык, на котором я лучше всего. Однако я также хорошо владею C. Скажу в части моего Программа мне нужна для вычисления действительно сложного уравнения. Я бы использовал для этого нативный метод, потому что я знаю немного C ++ и знаю, что C ++ намного быстрее, чем Java, поэтому, если бы я написал свой метод на C ++, он был бы быстрее. Также, скажем, я хочу взаимодействовать с другой программой или устройством. При этом также использовался бы нативный метод, потому что в C ++ есть что-то, называемое указателями, что позволило бы мне сделать это.

Источник

Что такое нативные методы в Java и ​​где их следует использовать?

Нативный метод имеет тот же синтаксис, что и абстрактный метод, но где он реализован?

Что такое нативные методы в Java и ​​где их следует использовать?

Как только вы видите небольшой пример, становится ясно:

Main.Java :

main.C :

Скомпилируйте и запустите :

Выход :

Протестировано на Ubuntu 14.04 с Oracle JDK 1.8.0_45.

Итак, ясно, что это позволяет:

Это может быть использовано для:

с компромиссом более низкой мобильности.

Вы также можете вызвать Java из C, но сначала вы должны создать JVM в C: Как вызывать Java функции из C++?

Пример на GitHub для вас, чтобы играть с.

Метод реализован в «родном» коде. То есть код, который не запускается в JVM. Обычно он написан на C или C++.

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

Мне нравится знать, где мы используем родные методы

В идеале совсем нет. В действительности некоторые функции недоступны в Java, и вам нужно вызвать некоторый C-код.

Методы реализованы в C-коде.

Необходимость нативного кода Java:

надеюсь, что эти пункты отвечают на ваш вопрос 🙂

Собственные методы позволяют вам использовать код из других языков, таких как C или C++, в вашем коде Java. Вы используете их, когда Java не обеспечивает необходимую вам функциональность. Например, если бы я писал программу для вычисления какого-либо уравнения и создания его линейного графика, я бы использовал Java, потому что это язык, на котором я лучше всего. Однако я также хорошо владею C. Скажем, в части моего Программа мне нужна для вычисления действительно сложного уравнения. Я бы использовал для этого нативный метод, потому что я знаю немного C++ и знаю, что C++ намного быстрее, чем Java, поэтому, если бы я написал свой метод на C++, он был бы быстрее. Также, скажем, я хочу взаимодействовать с другой программой или устройством. Это также будет использовать нативный метод, потому что в C++ есть что-то, называемое указателями, что позволило бы мне сделать это.

Источник

Русские Блоги

Изучая рабочий механизм JVM, я обнаружил, что область локального метода используется для выполнения собственного метода; так что в этом вопросе, что такое собственный метод?

Что такое Нативный метод

Объявление этих методов описывает, как выглядит не-java-код в этом java-коде.

Нативный идентификатор может использоваться со всеми другими идентификаторами Java.
За исключением abstract;, поскольку native подразумевает, что эти методы имеют тела реализации, но эти тела реализации не являются java, но abstract ясно указывает, что эти методы не имеют тел реализации.
Когда нативный метод используется вместе с другими идентификаторами Java, его смысл такой же, как и в случае нативного метода.

Собственная статика указывает, что этот метод можно вызывать напрямую, без создания экземпляра класса, что очень удобно;

Третий метод выше использует собственную синхронизацию, и JVM выполнит механизм блокировки синхронизации перед входом в реализацию этого метода (точно так же, как многопоточность Java).

Собственный метод может возвращать любой тип Java, а также может реализовывать управление исключениями;

Реализация этих методов вызывает исключение и выбрасывает его, что аналогично методу Java;

Когда собственный метод принимает некоторые неосновные типы, метод может получить доступ к внутренним компонентам этих неосновных типов, но это сделает собственный метод зависимым от реализации класса Java, к которому осуществляется доступ; это не так удобно, как использование функций на языке Java

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

JVM будет контролировать все детали вызова локальных методов

Класс, содержащий локальный метод, наследуется, подкласс унаследует локальный метод и может переписать этот метод на языке java (это кажется немного странным), то же самое, если локальный метод идентифицирован fianl, он не может быть унаследован Переписать

Собственные методы расширяют JVM;

Зачем использовать нативный метод

В Java непросто реализовать некоторые уровни задач в Java;
неэффективен для некоторых программ;

Взаимодействие между Java и средой за пределами Java

Это основная причина существования собственных методов: например, Java обменивается информацией с некоторыми базовыми системами, такими как операционные системы или некоторое оборудование;
Собственный метод предоставляет очень лаконичный интерфейс без необходимости знать детали вне приложения Java;

Взаимодействовать с операционной системой

JVM поддерживает сам язык Java и библиотеки времени выполнения; JVM также полагается на некоторую базовую поддержку; посредством использования собственных методов Java реализует взаимодействие между jre и системой формирования; при использовании некоторого языка Java сам по себе не обеспечивает характеристик инкапсулированного операционная система, нам также необходимо использовать локальные методы;

Sun‘Java

Интерпретатор Sun реализован на C; большая часть jre реализована на Java, который взаимодействует с внешним миром через некоторые локальные методы; например: метод setPriority () java.lang.Thread реализован на Java, но его реализация вызывает это class Локальный метод setPriority0 (); этот локальный метод реализован на C и имплантирован внутри JVM;

На платформе Windows 95 этот собственный метод в конечном итоге вызовет API Win32 SetPriority (). Это конкретная реализация локального метода, напрямую предоставляемого JVM. В большинстве случаев локальный метод предоставляется внешней библиотекой динамической компоновки, а затем вызывается JVM.

Как JVM запускает собственные методы

Когда класс используется впервые, байт-код этого класса будет загружен в память и будет перезагружен только один раз. Запись загруженного байт-кода содержит список всех дескрипторов методов этого класса. Эти дескрипторы методов содержат такую ​​информацию: где хранится код метода, какие параметры он имеет, дескриптор метода (открытый класс) и т. Д.

Источник

В нативный код из уютного мира Java: путешествие туда и обратно (часть 1)

Java и другие управляемые языки просты и удобны во многих случаях, но иногда их возможностей недостаточно — например, если нужна библиотека, написанная только на C или C++. Иногда хочется позвать пару методов из системного API, или попытаться улучшить производительность для модуля — и тогда прямой путь в нативный код.

Но тут возникают подводные камни: написать нативный метод и вызвать библиотеку может быть и легко, но JVM начинает крашиться в случайных местах, производительность падает, сборщик мусора перестает справляться с работой, а в репозитории царствуют бесконечные C-шные файлы с буквами JNI. Что же могло пойти не так?

Иван Углянский (dbg_nsk) из Huawei разбирается со всем по порядку: что необычного в интеропе между Java и нативным кодом, как оно работало раньше и что нужно делать для их нормальной совместной работы (и можно ли это вообще сделать). Иван рассказывает, как избежать просадок производительности, внезапных OOM и размышляет на тему будущего — в контексте проектов Panama и Sulong.

Мы подготовили текстовую версию доклада о работе с нативами в Java. В первой части:

Во второй части подробнее расскажем, какие есть варианты, что из них быстрее и лучше, и есть ли универсальная библиотека — всё с примерами кода и подсказками.

Далее — повествование от лица спикера.

Сегодня мы говорим про нативный код, про путешествие из Java в него и обратно. Дело в том, что я JVM-инженер, 7.5 лет работал в Excelsior, где мы делали собственную виртуальную машину Excelsior JET, а вот уже чуть больше года работаю в компании Huawei, в команде Excelsior@Huawei, где мы продолжаем заниматься своим любимым делом: компиляторами, JVM и новыми языками программирования.

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

В Java есть такая интересная фича — вы можете написать методы без тел, зато со специальным ключевым словом native:

Это означает, что реализацию этих методов стоит искать где-то ещё, например, в подгружаемых динамических библиотеках. И написана она может быть на каких-то других языках, например, на C/C++ или любом другом языке, где можно сделать C-like бинарные интерфейсы.

Бывают как простые сценарии, так и более сложные, что показывают уже методы на примере выше. Если вызываете первый метод goNative, то просто переходите из Java в C. А вот метод goThere позволяет перейти из Java в C, передать туда Java-объект callback и вызвать от него уже Java-метод.

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

Зачем нам нужны нативы

Java — замечательный managed-язык, в котором очень много всего сделано для вашего удобства.

Там есть автоматическое управление памятью, и вы, наверное, уже отвыкли от проблем, типа утечек памяти, висячих ссылок и прочего — всё это осталось где-то в районе C, а в Java есть GC, который с этим хорошо справляется.

И вообще Java — безопасный язык. Даже если вы, например, выйдете за пределы массива, вместо ужасного развала, как было бы в С, вы получите красивое исключение, которое можно обработать, понять, что произошло, и с этой ситуацией разобраться.

Получается, что Java — это такой Шир из Средиземья: абсолютно безопасное, удобное, приятное для жизни место, где все стараются сделать так, чтобы у вас всё было хорошо, и ничего не ломалось.

Если вы не будете выходить за его границы, то, скорее всего, ничего плохого действительно не произойдет.

А вот нативный код — это его полная противоположность. Это Мордор, где шаг влево-вправо, и вас сжирает горный тролль.

Но знаете, иногда нужно выходить из уютного Шира и идти в путешествие к Роковой горе.

Кроме того, вы можете захотеть получить что-то напрямую от операционной системы. Допустим, вы хотите узнать, какой прокси стоит у вашего пользователя — напрямую из Java вы этого не сделаете, вам опять-таки нужно опуститься на уровень нативного кода и дёрнуть метод, например, из WinAPI в случае Windows.

Есть ещё одна мотивация. Многие люди привыкли думать, что Java тормозит, а вот C++ — это очень быстро. Поэтому если взять и переписать самый performance critical модуль проекта на плюсы, связать всё это через нативы, то получится огромное ускорение производительности. Почему эта мотивация довольно сомнительная, я покажу ниже, но в любом случае она присутствует.

Наконец, в самом JDK много чего реализовано через нативные методы. Поэтому вы в любом случае сталкиваетесь с этим каждый день, так что неплохо было бы понимать, как это работает.

И вот вы полны энтузиазма, написали своё приложение наполовину на С, наполовину на Java, запускаете, ожидаете, что сейчас всё ускорится, а в результате… получаете SIGSEGV, Exception_Access_Violation или ещё один SIGSEGV.

В общем, ваше путешествие из Шира в Мордор заканчивается очень быстро, как у Боромира. Развал страшный, выглядит так, будто вообще сломалась сама виртуальная машина. Некоторые даже репортят баги, мол, JVM развалилась.

На самом деле чаще всего проблема в том, что они неправильно используют нативы.

В этом посте я в первую очередь хочу разобраться, почему так много проблем, почему люди получают SIGSEGV с нативами, во-вторых, показать вам безопасный путь, как можно пройти из Шира в Мордор, не отстрелить себе ногу, и не получить SIGSEGV, чтобы всё было безопасно и хорошо.

По ходу повествования мы будем все время сверяться вот с такой картой «Как позвать натив?»

Если вы идете из Шира в Мордор, вам нужно ответить на три вопроса:

Ответы на эти вопросы подсветят нам самые больные места в механизме нативных вызовов и помогут избежать проблем.

История до нашей эры

Сначала чуть-чуть истории.

Нативы можно было вызывать в Java ещё в самом начале, буквально в JDK 1.0 уже был Native Method Invocation, который позволял вызывать C-шные методы. Но он был заточен на детали реализации одной конкретной виртуальной машины, а именно на Sun JVM. На то, как там лежат объекты в памяти, какой сборщик мусора там используется.

Были и альтернативы. Например, Microsoft предлагала свой Raw Native Interface. Он был в чем-то лучше, в чем-то хуже, но тоже работал только с одной виртуальной машиной — теперь уже Microsoft J++.

Были попытки сделать нейтральные решения, как у Netscape, но в целом это были тёмные времена. Когда вы писали натив, вы не могли быть уверены, что это будет работать на всех JVM или хотя бы на каких-то.

Наша эра: JNI — Java Native Interface

Наша эра начинается с появления знаменитого Java Native Interface или JNI. Это был единый интерфейс, чтобы править всеми, и он был прекрасен, потому что был JVM нейтрален.

Он никак не затачивался на то, как сделана конкретная виртуальная машина, не важно, какая раскладка по объектам в памяти, неважно какой GC.

Если виртуальная машина поддерживает JNI, гарантируется, что ваш натив там заработает. Далее я буду говорить про JNI много плохого, но хочу акцентировать внимание: на тот момент это был огромный прогресс для всей отрасли, наконец-то мы могли писать нативы без страха, что они где-нибудь не заведутся.

Давайте посмотрим, как это работает.

Со стороны Java всё выглядит довольно мило, вы это уже видели.

Пишем методы без тела, пишем где искать реализацию, например, в System.LoadLibrary говорим подгрузить dll-ку, и после этого просто вызываем этим методы и переходим в С или С++.

Callback — это просто класс, у которого есть метод call, ничего не возвращающий, который печатает строку «Ok, we are in Shire again!», в моём случае мы вернулись в Шир на орлах.

Как получить заголовку функций?

Теперь давайте попробуем написать нативную часть на языке С.

Здесь всё будет уже не так красиво, но нам нужно это сделать.

В результате мы получаем JavaToNative.h со всеми заголовками, но при этом то, что там написано, не очень-то похоже на нашу функцию.

Здесь появились какие-то заклинания типа JNICall. Здесь совсем другое имя метода: оно содержит еще и package и имя класса. И сигнатуры отличаются! У нас был 1 аргумент типа Callback, а здесь их уже три и они совсем другие.

jclass появился, потому что натив был статическим и этим параметром передается Java-класс, чей статический метод вызывается. Callback превратился в jobject и появился новый JNIEnv со звёздочкой (про него чуть позже).

Правила, по которым генерируются заголовки, очень четкие и описаны в JNI-спецификации. Все примитивные типы превращаются в соответствующие примитивные C-шные (заданные макросами и базирующиеся на С-шных примитивных типах), все референс-типы превращаются в jobject или в редких исключениях в его наследников — jclass, jstring, jthrowable, jarray.

Это ответ на первый вопрос в нашей карте — как виртуальная машина должна находить реализации методов. Она это делает по именам, знает все эти правила и в подгруженной библиотеке ищет соответствующие правильно называющиеся нативные методы.

Что за JNIEnv?

Аргумент JNIEnv * — это указатель на таблицу из 214 специальных функций, которая называется JNINativeInterface.

Вот некоторые из них:

А вот некоторые важные из них, которые, скорее всего, чаще всего используются.

JNINativeInterace помогает нам программировать на метауровне — как будто бы на Java, но используя мета-сущности: handle для классов, методов и так далее. Например здесь вы можете получить handle Java-класса, через него создавать его экземпляры (Java объекты), вызывать Java методы через специальные функции Call*Method, выбрасывать исключения.

Это очень похоже на рефлексию, только вы занимаетесь этим не в Java-коде, а в C.

Все эти функции JNI-интерфейса — единственный способ хоть как-то взаимодействовать с Java-миром: либо с объектами, либо просто получить информацию от виртуальной машины.

И это ответ на второй вопрос в нашей карте: как взаимодействовать с JVM. Вот так — через 214 функций, которые являются вратами в Шир.

Теперь давайте напишем нашей функции тело.

Для этого я получаю jclass, соответствующий классу моего аргумента, нахожу в нём метод, который называется call, возвращающий void, и вызываю этот метод с помощью JNI-функции CallVoidMethod. Должна напечататься строка, что мы вернулись на орлах и всё ок.

Как все это собрать?

Наконец, давайте обсудим, как все полученное ранее собрать.
Я использую Windows, поэтому гуглю заклинание, как собрать нативную библиотеку для JNI на этой системе:

В результате у нас получается библиотека NativeLib.dll.

Это, конечно, довольно неприятно с точки зрения кроссплатформенности. Потому что, если вы собираете библиотеку для Linux или macOS — заклинания будут другими.

К счастью, есть замечательные тулы, которые позволяют от всего этого абстрагироваться. Например, Nokee plugins. Это кроссплатформенное решение, которое позволяет удобно добавить таргет в gradle скрипт и в результате собрать библиотеку под интересующие вас платформы.

Окей, тем или иным способом мы библиотеку собрали, после чего запускаем наше Java приложение, и получаем…

Ура, мы только что совершили свое первое путешествие в Мордор и вернулись обратно. Теперь давайте поговорим, что же при этом может пойти не так. Кроме того, что нам пришлось пописать на не самом приятном языке C, да и выглядит это все довольно ужасно.

Что может пойти не так?

А пойти не так может очень много вещей…

В первую очередь, когда вы переходите в нативный код, вы теряете статическую типовую информацию.

Да, вы передавали объект callback, но он превратился в jobject, и какой был тип изначально — сходу не видно.

Допустим, у меня был бы какой-то другой аргумент, теперь уже java.lang.Object. И он бы тоже представлялся в нативном коде, как jobject, а потом я могу совершенно случайно по невнимательности позвать CallVoidMethod, передав туда в качестве аргумента не Callback, а какой-то java.lang.Object и попытаться из него позвать метод call (которого там, конечно, нет).

Меня не остановит компилятор, не остановит runtime ровно до тех пор, пока не случится развал из-за попытки позвать call от java.lang.Object.

Абсолютно похожая история с тем, какую конкретно JNI-функцию вы вызываете. Никто не проконтролирует, что вы используете именно СallVoidMethod, а не CallBooleanMethod или CallStaticVoidMethod или ещё что-то — это будет ваша ответственность. Если вы ошиблись, то случается неопределенное поведение (прям как в плохих программах на С), что начнет делать виртуальная машина — неизвестно.

Еще один момент, на который стоит обратить внимание: когда вы вызываете из натива Java-метод, он вполне может выбросить исключение, после чего исполнение возвращается в натив. В Java мы привыкли, что необработанное исключение автоматически пролетает дальше, ничего дополнительного делать не нужно. Но в данном случае это снова ваша ответственность! Вы должны проверить, а не случилось ли при вызове Java-метода исключения (с помощью функций ExceptionCheck или ExceptionOccurred), и если так, то обработать его здесь (с помощью ExceptionDescribe и ExceptionClear). Если же вы этого не сделаете, то в следующий раз, когда исполнение придет в Java-код, это исключение полетит уже совсем из другого неожиданного для вас места, и вы снова получите некорректное поведение.

Вместо страшного и ужасного развала вы получите привычное исключение с понятным stacktrace, где будет написано, что вы перепутали MethodID или же используете не тот объект при вызове (что, собственно, у нас и происходит!).

Это помогает быстро понять проблему и разобраться в большем проценте ошибок с нативами.

Это не означает, что будут вылечены все проблемы, но все самые простые — да.

Garbage Collector и Native-код

А теперь поговорим про последний пункт в нашей карте — как GC должен взаимодействовать с нативным кодом.

Почему про это вообще нужно говорить? Дело в том, что в Java коде, когда JVM нужно пособирать мусор, она приостанавливает Java потоки в специальных сгенерированных компилятором точках, которые называются GC safepoints. Давайте для простоты рассматривать случай StopTheWorld-коллекторов. В таком сценарии только после того, как все Java-потоки достигли ближайших safepoints и приостановились, начинают работать GC-треды, которые, собственно, собирают мусор.

Это важно, потому что GC может двигать объекты во время своей работы. Для компактизации кучей, для своих каких-то целей — неважно. Если в этот момент кто-то из Java-тредов будет смотреть и взаимодействовать с Java хипом — читать или записывать поля некоторого Java объекта, то может случится неприятная ситуация: этот объект просто украдут у него из-под носа и перенесут в другую часть памяти. В результате вы получите некорректное поведение (например, развал).

Так вот проблема с safepoints в том, что в нативном коде такой фокус не пройдет.

Safepoints вставляют компиляторы из JVM, а если это какой-то внешний код, например на C или C++, скомпилированный clang-ом, то там нет никаких safepoint! В результате, мы просто не сможем остановить наши потоки, которые исполняют натив, чтобы пособирать мусор. Поэтому мы вынуждены смириться с тем, что нативы будут работать параллельно со сборкой мусора.

И тогда схема меняется так: появляются новые действующие лица, треды, исполняющие нативный код. Допустим, они ушли в натив до того, как нам потребовалось пособирать мусор, и вот они спокойно будут работать параллельно с GC-тредами.

Есть ограничения. На входе в натив нам нужно сказать сборщику мусора: мы ушли в натив, не жди нас, спокойно собирай мусор. На выходе надо проверить, а не идет ли сейчас сборка мусора, и если идёт — приостановиться.

Но при этом всё ещё возникает проблема: даже в нативе вы не имеете права трогать Java-объекты, которые сейчас может взять и двигать GC.

Как вы помните, все наши Java-объекты в нативах почему-то превратились в jobject.

Оказывается, что jobject — не просто маппинг для Java-ссылок, а специальные низкоуровневые хендлы, которые внутри инкапсулируют адрес на реальный Java-объект.

Гарантируется, что Java-машина поддерживает связь этого адреса с реальным адресом объекта. То есть, если мы подвинули объект, то соответствующий jobject тоже будет пропатчен автоматически.

С другой стороны, единственный способ повзаимодействовать с Java-миром из натива — это JNI-функции, которые также работают с jobject. Почти во всех из них стоит синхронизация с GC, так что вы не сможете сделать с объектами ничего плохого, пока идет сборка мусора.

Если последним использованием ваших объектов была передача их в нативный код, то гарантируется, что за время исполнения этого натива их никто не соберет. Эти jobject являются своеобразными GC-root, что гарантирует выживание объекта.

Поговорим о том, какие проблемы это может вам доставить.

JNI References

Первая и главная проблема в том, что для хендлов реализована альтернативная система управления памятью. Это не похоже ни на Java, ни на C, скорее, что-то среднее между ними. Всё, что вы в коде видите, как jobject, на самом деле является сложным объектом JNI Reference, причем они бывают трех разных типов.

Во-первых, local references.

Они называются так, потому что они существуют не дольше, чем исполняется нативный метод, в котором был создан local reference (полная аналогия с локальными переменными).

Они интересны, во-первых, тем, что большинство JNI-reference — это именно LR. Передали какие-то Java-аргументы в натив — они автоматически заворачиваются в локалрефы, вызываете JNI-функцию, создающую объект — из нее тоже вернется локалреф. А во-вторых, с этими штуками, несмотря на, казалось бы, очень естественную и простую схему очистки, чрезвычайно легко получить утечку памяти.

Продемонстрирую это на небольшом примере:

Здесь мы будем аллоцировать в огромных количествах объекты прямо из нативного кода. Для этого находим соответствующий класс BornInNative с помощью JNI-функции FindClass, а получаем конструктор и метод-предикат, который будет говорить по соответствующему инстансу, нужно ли создавать следующий объект или нет. А потом просто в нативном коде с помощью JNI-функции NewObject начинаем эти объекты создавать.

NewObject аллоцирует память, вызывает конструктор, который создает объект и возвращает в нативный код ту самую local reference, которую затем сохраняем в переменную obj типа jobject. От неё вызываем предикат, чтобы понять, нужно ли дальше аллоцировать объекты или нет.

Вот если вы написали такой код на Java, у вас бы не возникло сомнений в том, что здесь всё хорошо с управлением памятью. Как только проходит очередная итерация цикла, созданный на этой итерации объект уже никому не нужен, а значит, GC когда-нибудь придёт и соберет его, например, если памяти будет не хватать для очередной аллокации.

На Java бы всё работало, но в нативном коде вам такого никто не гарантирует. Про Local reference гарантируется, что они умирают не позже, чем возврат из нативного метода. Но это и все: сами по себе от того, что вы переназначили переменную на другую LR, они умирать не обязаны и не будут.

Через несколько сотен миллионов итераций мы заметим, что аллокации стали фейлиться. JVM сейчас в коматозном состоянии, она пытается выкинуть out of memory, но ничего не получается, ведь в нативе мы это не обрабатываем. Обратите внимание на потребление памяти.

Вы заказывали 1 ГБ, но потребление на самом деле уже 2 ГБ, потому что а) все Java-объекты удерживаются в heap, б) сами неумирающие jobject тоже занимают (нативную) память. В результате реальное потребление памяти вашим приложением превысило указанный лимит на дополнительный гигабайт.

Чтобы это починить, есть специальная функция DeleteLocalRef, которая говорит JVM, что локальная ссылка больше не нужна, ее можно уничтожить, а соответствующий объект собрать во время GC.

Исправленная программа будет работать с любым разумным Xmx.

Так что с local Reference легко получить memory leak, но также легко получить и висящую ссылку. Попробуйте сохранить LR в static-поле, выйти из натива, вернуться и прочитать это поле. Получите некорректное значение.

Кроме LR есть другие хендлы, например Global Reference. Такие ссылки существуют до тех пор, пока вы явно их не освободите. Здесь ещё легче получить утечку памяти (достаточно просто забыть вызвать DeleteGlobalRef), но с другой стороны они более прямолинейны, нет неожиданностей. Забыли позвать DeleteGlobalRef — значит, будет утечка.

Наконец есть Weak Global Reference, это GR, но в них не гарантируется, что GC не соберет ваш объект. Это полная аналогия со слабыми ссылками из Java. Таким образом, все проблемы с ними актуальны и для нативов тоже.

Еще больше сложностей с GC

Кроме проблем с JNI Reference стоит упомянуть, что у некоторых функций JNI-интерфейса есть очень интересные отношения со сборщиками мусора. Допустим, вы передаете в натив массив, он завернется в jobject, но получать доступ к каждому элементу по одному через jni-функции — это очень долго.

Вместо этого вы наверняка захотите получить доступ ко всему региону данных из массива за раз. Для этого есть специальные функции, например, GetIntArrayElements. Однако у нас опять есть проблема: мы не можем получить доступ к объекту, если в этот момент его может подвинуть GC. С этим нужно что-то сделать.

Есть две техники, как это можно реализовать. Во-первых, можно «запинить» объект, сказать сборщику мусора «давай мы не будем двигать пока массив, ты собирай мусор, а его не двигай».

Вторая тактика — просто скопировать его в нативную память, в нативе поработаем с копией, а потом обновим соответствующий массив.

JNI функции типа GetIntArrayElements даже поддерживают такую двойственность решения этой проблемы: у них есть третий аргумент — указатель на флажок. Если виртуальная машина решилась скопировать, то туда запишется true, если нет, то false, так что вы узнаете, что конкретно произошло.

Подводный камень здесь в том, что большинство виртуальных машин и сборщиков мусора не умеют pin-ать объекты по одному. Есть исключения, но скорее всего, как бы вы не надеялись на то, что копирования не случилось, оно произойдет. Так что при работе в нативе с массивом на 2 ГБ вы столкнетесь с копированием его в нативную память, что, конечно, может ударить и по производительности, и по общему потреблению памяти вашим приложением.

Конечно, есть особенные JNI-функции типа GetArrayElementsCritical (и другие функции с суффиксом Critical), они всячески стараются не скопировать массив.

Пиннинга в большинстве GC нет, как они выходят из ситуации?

Они говорят: «Давайте на время исполнения этой функции вообще не будет сборки мусора, пусть GC подождёт». Это может сработать и дать хорошую производительность, вы поработаете без копий, но есть и обратная сторона медали.

Вы отодвигаете GC на неопределенный срок, что уже плохо само по себе, но при самом плохом сценарии вы можете просто получить дедлок и зависание вашего приложения. Подробнее про это можете почитать в посте Алексея Шипилёва.

Производительность нативных методов

И наконец, нельзя говорить про нативы и не обсудить их производительность. Раз вы вызываете C-код, то, конечно, кажется, что это должно чертовски быстро работать по сравнению с обычной Java. На самом деле — это большое заблуждение. Дело в том, что сам вызов нативных методов — это серьезная сложность для виртуальной машины. Давайте измерять!

Все замеры будем проводить на машине: Intel Core i7-7700 @ 3.60 GHz;16GB RAM, Linux Ubuntu 18.04

Начнем с простого примера. Мы из Java вызываем другой Java метод без параметров и обязательно без инлайна. Мерим это с помощью JMH, получаем 696 попугаев, (больше — лучше).

Проведем другой эксперимент и вызовем из Java нативный метод, тоже пустой, без параметров и возвращаемого значения. И получаем просадку производительности в 3,3 раза на jdk8u252.

При этом на jdk11 вы уже получаете просадку уже в 6 раз. Причины такой разницы в поведении разных версий Java рассмотрим в конце доклада, а сейчас продолжим наши измерения.

Теперь давайте проведем более зловещий эксперимент и вызовем из Java натив, а оттуда через callback позовём пустой Java-метод. Логично предположить, что здесь случится проседание раза в два (ведь стало в два раза больше работы). На самом деле просадка будет в 10 раз.

Т.е.возвращаться обратно из Java в натив дороже, чем просто уходить в натив.

Почему так происходит?

Если вы вызываете нативный метод, то, конечно, в сгенерированном коде хочется увидеть просто инструкцию call, вызывающую этот метод по какому-то адресу.

И вы этот call получите, но вокруг него есть ещё некоторое количество работы для подготовки к вызову и обработки результата.

Более конкретно кроме самого вызова нам нужно:

И всё это даёт просадку производительности в шесть раз.

Вторая волна просадки производительности происходит, когда мы понимаем, что никакого инлайна не будет. Абсолютно враждебный код, он написан на другом языке, а скомпилирован другим компилятором. У нас просто нет технической возможности проинлайнить это в Java. Поэтому в нашем первом измерении мы вызывали Java метод без инлайна, иначе разница была бы настолько огромная, что на одном графике результаты показывать уже не было бы смысла.

Ну и про возвращение обратно в Java — так медленно работает из-за реализации конкретной виртуальной машины Hotspot. Когда вы делаете callback, происходит много лишней и тяжелой работы, в других виртуальных машинах результат мог бы быть гораздо лучше.

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

Подведем итог этой части доклада одним предложением — «Появление JNI в своё время было огромным прорывом в отрасли, но использовать его сегодня для взаимодействия с нативным кодом слишком уж больно».

В следующей части поговорим про сегодняшние альтернативы JNI, их сильные и слабые стороны, а также обсудим будущие проекты, которые вполне могут кардинально поменять все наше представление о нативах в Java: проекте Panama и Sulong.

Минутка нативной рекламы в тексте про нативный код. Раз вы здесь — похоже, вы Java-разработчик, который не боится покидать уютную хоббичью нору и покорять что-то новое для себя. В таком случае на конференции Joker (25-28 ноября, онлайн) наверняка будет интересное для вас — можете сами посмотреть программу на сайте.

Источник