JNI: накладные расходы на хранение ссылок на объекты Java в машинном коде?

#java #c #performance #java-native-interface #reference

#java #c #Производительность #java-native-interface #ссылка

Вопрос:

Я рассматриваю возможность интеграции JRE в приложение C через JNI.

Каковы накладные расходы на хранение большого количества ссылок на объекты Java в приложении C (глобальные ссылки на языке JNI)?

Существуют ли какие-либо проблемы, о которых я должен знать при таком подходе (кроме очевидных, таких как освобождение ссылок вручную)?

Ответ №1:

(a) накладные расходы такие же, как если бы вы делали это с Java. Вы препятствуете сбору мусора для объектов.

(b) Хранение ссылок на объекты в вызовах JNI может быть фатальным для JVM, если вы не сделаете это правильно. Вам нужно внимательно прочитать раздел о глобальных и локальных ссылках в спецификации JNI. Вам также необходимо рассмотреть возможность использования слабых ссылок вместо глобальных.

Ответ №2:

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

Как правильно указывает EJP ( 1), если вы неправильно управляете своими Java-объектами JNI, произойдут очень плохие вещи, в том числе виртуальная машина просто умрет. Я также обнаружил, что код JNI очень сложно протестировать.