Nous sommes confrontés à un problème de performance une fois que l'application Java Swing est déplacée de Java 6 32 bits à Java 7 32 bits Update 11. Quelqu'un peut-il offrir une certaine indice à ce sujet?
L'application utilise la technologie Java Web-Start et le serveur est Tomcat 7. L'application client consomme 1 Go de mémoire, de sorte que l'écran gèle.
Nous échangeons des objets sérialisés, suivant est Le code: Il n'y a pas de changement dans le code uniquement Le JVM est mis à jour. J'ai pris l'instantané de mémoire pour JDK 1.6 et JDK 1.7 à l'aide de Java VisualvM, en suivant est le lien vers le fichier RAR. qui contient les instantanés: instantanés de mémoire à l'aide de Java VisualvM
Voldule de tas à l'aide de Java Visualvm L'IDE NetBeans fournit une option pour migrer le code de Java 6 à Java 7. Vous trouverez ci-dessous le lien concernant ceci: https://netbeans.org/kb/docs/java/editor-inspect-transform.html#convert sera-t-il une bonne option pour la migration de la source entière Code de Java 6 à Java 7 sans aucun problème? Ou quelqu'un estime que cela pourrait créer un problème? Et si nous le faisons, si nous pouvons résoudre ce problème de performance à une certaine prolongation?
3 Réponses :
Je pense qu'il y a trop d'explications possibles et trop peu de preuves difficiles dans la question pour dire quel est le problème.
Je vous suggère de:
Notes:
Vous dites:
Il n'y a pas de changement dans le code uniquement Le JVM est mis à jour.
Sauf que même s'il n'y a pas de changement dans votre code, il y a potentiellement beaucoup de changements dans:
- Le code d'exploitation
JVM , - Le code de la bibliothèque de classe .
Modifications de la mise en œuvre de JVM
Cela pourrait déjà utiliser davantage de mémoire pour son processus. Ce n'est pas exactement quelque chose qui serait couvert par les spécifications JVM et vous ne pouvez pas faire grand chose à ce sujet.
Code de la bibliothèque de classe
Son empreinte statique peut être plus grande, de sorte que la JVM charge ses bibliothèques normales, elle consomme déjà une partie de la mémoire allouée. Mais, plus probablement, c'est aussi votre utilisation de cet usage comme un impact. Dites une classe que vous utilisez souvent comme modifiée sa mise en œuvre interne et utilise plus de mémoire que dans 1.6.x, et cela signifie que votre programme utilise maintenant plus de mémoire pour chaque instance de cet objet que vous détenez.
Donc, vous pourriez avoir des chiffres de consommation de mémoire assez variés ici. Par exemple, la mise en œuvre de la hachage des cartes de hachage modifiées (bien que cela ne puisse pas changer la quantité de mémoire qu'il utilise dans son état final), certaines structures de données de base peuvent avoir des internes différents (j'espère que non), et des composants plus compliqués peuvent être un beaucoup plus différent de celui-ci (enregistreurs, utils, données et processeurs d'événements, etc.).
Tout ce qui a changé dans la classeLib et que vous utilisez ou que toute bibliothèque que vous référence utilise vous-même peut expliquer cette différence et être suffisante pour que vous puissiez aller à la mer.
Manières possibles à une résolution
Profil!
Prenez des instantanés de mémoire de votre programme après le démarrage à l'aide des deux configurations et comparez la consommation pour chaque classe. Voyez ce qui a changé, ce qui peut être retourné, coupé, substitué de quelque chose d'autre ou largué entièrement.
lancer plus de ressources au problème
C'est la solution no-évidente, mais c'est souvent une solution assez bonne, si ce n'est pas un problème opérationnel pour vous ou les clients utilisant votre programme.
Achetez plus de RAM et augmentez les paramètres de mémoire de votre JVM.
Le OOS ObjectOutputStream se construit dans la méthode, mais il ne ressemble pas à vous jamais le fermer. Fermeture du flux se libérer de la mémoire.
Quand les ordures ObjectOutputStream get collectées? ObjectOutputStream et ObjectInputStream garder lecture et des objets écrits dans la mémoire . Cela ressemble à une fuite de mémoire.
Je vous suggère d'ajouter enfin des blocs pour être sûr que les cours d'eau get fermé. Je ne peux pas dire ce que la durée de vie des objets sérialisés est de ce que vous avez publié, mais vous pourriez bénéficier de l'utilisation du readUnshared et des méthodes writeUnshared.
Vous avez écrit:
Sera-ce une bonne option pour la migration de l'ensemble du code source de Java 6 à Java 7 sans aucun problème? Ou quelqu'un estime que cela pourrait créer un problème? Et si nous le faisons, si nous pouvons résoudre ce problème de performance mis à une certaine mesure?
Vous ne bénéficiera pas d'utiliser un outil pour mettre à jour le code à 1,7. Si vous avez fait que vous ne serait plus en mesure d'exécuter votre code 1.6. Je vous recommande d'utiliser les inspections « Performance » de NetBean. , Je recommande fortement également en cours d'exécution FindBugs contre votre base de code.
Heapdumps
- La décharge jdk 1.7 a été prise du tas quand 53M a été utilisé.
- La décharge JDK 1.6 a été prise lors de 61M ont été utilisés.
Les heapdumps vous sont pas posté utile, car on dirait qu'ils ont été prises avant que la mémoire était un problème. Vous devez prendre un heapdump alors que le système utilise beaucoup de mémoire afin que vous puissiez examiner la décharge et savoir où la mémoire est utilisée.
Ajoutez
-XX: + HeapDumpOnOutOfMemoryError option jvm. Avec cette option java prendra automatiquement sa propre heapdump quand il est à court de mémoire.instantanés
** Bien que vos photos archive a quatre fichiers qu'il contient, deux des fichiers sont des doublons avec des noms différents. Regardez les tailles et les checksums et vous verrez qu'ils sont les mêmes. **
Les instantanés sont plus informatifs, mais ils semblent aussi avoir été prise avant la quantité de mémoire a été utilisée.
L'instantané 1.7 a de nombreux cas, plus de chaînes de caractères.
Les 1,6 ressemble instantané comme celui-ci:
Le look 1.7 instantané comme:
chaîne .Substring actions ne sont plus un tableau de caractères sous-jacent . Cela peut être une différence assez importante dans le code qui fait beaucoup de manipulation de chaînes.
Les char [] tenir les données réelles dans vos objets String. Je prendrais regarder de plus près ce que les objets et comment tenir les jeux ces cordes se construisent.
Sera-t-il une bonne option pour la migration du code source entier de Java 6 à Java 7 sans aucun problème? Ou quelqu'un estime que cela pourrait créer un problème? Et si nous le faisons, si nous pouvons résoudre ce problème de performance à une certaine prolongation?
"Quelqu'un peut-il offrir une idée de cet indice" <- et qu'en est-il de [insérer votre moteur de recherche préféré ici]? En outre, vous ne racontez rien de l'environnement à l'écart des versions JVM; Qu'en est-il du système d'exploitation?
Aussi: Quels composants causent cette perte de performance? Pouvez-vous quelque peu réduire-la à des stérriers avec seulement certains composants?
La mémoire de 1 Go est-elle plus qu'avant? Si oui, avez-vous également changé à une JVM de 64 bits?
Avez-vous essayé de recompiler les applications avec Java 7?
@Adrian Oui, nous nous sommes conformés à l'aide de Java 7 Update 11 (64 bits)
Échangez-vous des objets sérialisés, Datainput / Provitenstreams? Rmi? Aidez les lecteurs en fournissant plus de notes. Peut-être un bon moment pour Qa: essayez les secteurs de Findbugs.
@Ryan C'est la première fois que je travaille sur la question de la performance et nouvelle dans tous les outils tels que VisualvM, j'ai donc pris un instantané avant de vous connecter à l'application et après avoir effectué des fonctionnalités courantes pour JDK 1.6 et JDK 1.7. Snapshot Avant de vous connecter à l'application sont les suivants: Snapshot-jdk1.6beforelogin.nps: App exécutant dans JDK 1.6 Snapshot-jdk1.7beforelogin.ns: App exécutant dans JDK 1.7 Snapshot après avoir effectué les mêmes activités: Snapshot-jdk1.6final.nps: App exécutant dans JDK 1.6 Snapshot-jdk1.7final.ns: App cours d'exécution dans JDK 1.7
@Leejoy Les fichiers ont la même somme de contrôle md5: 7d39d4f9fb6e5decc74ae24c37bc3a4e * / snapshot-JDK1.6BeforeLogin.nps 7d39d4f9fb6e5decc74ae24c37bc3a4e * / snapshot-JDK1.6Final.nps 088137e208f124f1539b528cb19cb2cb * / snapshot-JDK1.7BeforeLogin.nps 088137e208f124f1539b528cb19cb2cb * / snapshot-JDK1.... .7final.nps
Vous dites que l'écran est gelant, est-ce parce que vous manquez de mémoire? Assurez-vous que la console est visible et / ou d'écrire dans un fichier journal. S'il est à court de mémoire, vous devriez obtenir un exemplaire. Si oui, que meurent la stacktrace? D'autres raisons pour lesquelles l'interface utilisateur pourrait être congelée effectue une action synchrone (et longue durée) sur l'événement EventQueue.