C++ Girl
  1. C++ Girl
  3. JNI: gérer correctement la durée de vie d’un object Java
Intereting Posts
convertir unicode en char En recevant un tutoriel, j’obtiens une erreur: C ++ requirejs un spécificateur de type pour toutes les déclarations Utiliser enum dans les boucles et la cohérence des valeurs Que signifie le “L” à la fin d’un littéral entier? Comment faire référence à des structures récursives via des pointeurs utilisant des vecteurs Suppression des caractères spécifiés d’une chaîne – Méthodes efficaces (complexité temporelle et spatiale) C ++ simple taille-différence entre tableau de caractères et pointeur de caractères Comment puis-je déclarer une fonction de hachage à utiliser dans un unordered_set dans un espace de noms? Extension de C ++ ostream Déployer des fichiers binarys Qt Application sur Ubuntu avec des bibliothèques partagées Comment combiner des chaînes C ++ et des chaînes Arduino? Déclarer une fonction acceptant un iterator générique Comment gérer ou éviter un débordement de stack en C ++ Références circulaires entre deux classes zlib in Qt – QtZlib n’est pas présent

JNI: gérer correctement la durée de vie d’un object Java

Lorsque je crée un homologue d’implémentation native en c ++, comment puis-je m’assurer que la partie native est également supprimée lorsque l’object java est supprimé par la JVM? Je peux append certaines méthodes que l’utilisateur d’object java doit appeler explicitement, mais j’aimerais savoir s’il existe des points d’ancrage que je pourrais manipuler lorsque l’object java est supprimé (garbage collecté) afin de pouvoir supprimer automatiquement un object d’implémentation c ++. ainsi que.

J’ai examiné JACE, il semblerait que ce soit le cas, mais il faudrait que je lance PeerEnhancer pour corriger le fichier de classe généré (c’est probablement comme ça qu’il supprime la suppression? Ou peut-être qu’il a besoin de ce correctif pour autre chose). Cependant, je voudrais éviter de jouer avec les fichiers java compilés, je ne veux rien d’extraordinaire

C’est un cas rare où vous devriez vraiment utiliser un finaliseur, mais vous devriez aussi rendre votre classe Java Closeable.

Sachez qu’en choisissant les finaliseurs, vous chatouillez JVM au pire endroit possible. Invoquer JNI dans le finaliseur () revient à ajuster le calage des soupapes du moteur pendant la conduite. Bien que cela soit techniquement possible, il est également très facile de se retrouver avec une machine virtuelle Java qui coule ou un crash. Avec la moindre touche de multithreading, vous vous retrouverez à un moment donné dans une impasse. Si vous dites “je ne veux rien d’extraordinaire”, je suggérerais d’utiliser des méthodes explicitement appelées. Oui, nécessitant un certain ordre de méthode par convention, c’est du sale design, mais JNI est sale en général.

Si une bibliothèque JNI respectée fait une instrumentation de classe d’infiltration au lieu d’utiliser simplement des finaliseurs, elle a peut-être une raison. Quelques lectures recommandées (et cela ne mentionne même pas JNI!):

http://asserttrue.blogspot.com/2008/11/finalization-is-evil.html

http://elliottback.com/wp/java-memory-leaks-w-finalize-examples/

Ma suggestion est la suivante: oui, implémentez une classe de base avec une méthode virtuelle detachFromPeer (), définissez-y un indicateur “détaché” puis, dans le finaliseur, vérifiez-le avec un avertissement.