application Java fonctionne plus rapidement sur Windows 7 au mode de compatibilité Windows XP selon certains de mes clients, mais pourquoi?
Je ne semble pas avoir le problème moi-même, mais ils trouvent que la demande semble consommer 100% de la CPU tout en ne faisant rien, en définissant simplement les propriétés de l'EXE ou d'un fichier de commandes qui appelle le mode de compatibilité Java à Windows XP comment cela pourrait-il être?
3 Réponses :
C'est en raison de la commutation de tâches interne. La commutation des tâches sous Windows XP en mode de compatibilité est plus comparée à Windows 7. Cela peut provoquer une cause de pare-feu également. Vérifiez votre statut de pare-feu dans Windows 7.
Que voulais-tu dire? Changer quelles tâches, en interne à quoi? "La commutation ... est plus comparée à Windows 7". Plus de quoi? Pouvez-vous donner une source?
Je pense qu'il suggère qu'il suggère que la commutation de tâche interne en mode XP est plus performante que l'original 7 un.
Pas de réponse définitive, mais simplement un moyen de diagnostiquer sur le site ce qui se passe exactement.
Vous devez confirmer quel processus consommera la CPU et ce qu'il fait exactement, par exemple en surveillant les appels de système effectués: les sysinternals outils tels que Explorateur de processus et moniteur de processus devrait conduire à des indices sur ce qui peut être faux. Au moins, vous pouvez comparer le profil d'exécution avec versus sans mode de compatibilité XP.
Comme le problème peut provenir de l'application Java elle-même, vous devez essayer d'essayer un profilage JVM avec des outils tels que profileur NetBeans . Peut-être que le code s'appuie sur certaines de nombreuses choses spécifiques de Windows XP, telles que la structure de répertoires ou la variable d'environnement qui n'existant plus ou n'a plus changé dans Windows 7 (mais vous avez conservé / réappliquée sur votre propre installation) ... menant à une mauvaise manipulation d'erreurs et à une boucle infinie de tentatives par exemple.
Un profileur de Windows natif peut être une option aussi, mais il est beaucoup trop difficile d'analyser sans code source JVM et lorsque le code Java est concerné à cause de JIT.
Pas de solution directe, mais votre question est assez ouverte.
Si votre client peut reproduire cela de manière cohérente, vous pouvez voir si elles sont prêtes à vous envoyer un Demande d'assistance à distance , vous permettant de vous laisser sur leur bureau. Ensuite, au moins vous pouvez voir le problème en action et essayer de le déboguer sur leur machine en utilisant les outils mentionnés par d'autres.
Je ne dis pas que je sais pourquoi, mais avez-vous vérifié pour voir s'il s'agissait d'un JVM 32 bits ou d'un JVM 64 bits?
Soyez reconnaissant que vos clients ont trouvé une solution qui fonctionne pour eux. Votre application Java est-elle 32 bit ou 64 bits? Les machines Windows 7 de vos clients sont-elles 32 bits ou 64 bits?
Ouais, je pense que le Windows7 est 64 bits, l'application peut être de 32 bits ou 64 bits, pour être franc car je ne peux pas reproduire le problème moi-même que je me suis lutté pour suivre cela, mais je me demandais si quelqu'un pouvait comprendre pourquoi une application pourrait mieux fonctionner en mode de compatibilité
Peut-être que le wrapper est le principal coupable sur ceci (à l'aide de fonctionnalités Windows XP), à l'aide de quelle emballage utilisez-vous?
@RAFAEL, JSMOOK, mais une clientèle rapporte un problème simplement à l'aide d'un fichier de lot et de java pur
Eh bien, JSMOOK est de 32 bits uniquement et assez obsolète (la dernière version était en 2007), utilise probablement probablement les anciens appels Windows XP, concernant votre utilisateur utilisant uniquement un fichier de commandes, il peut utiliser une version obsolète de la JVM (comme 1,5 ou quelque chose comme ça).