2015-12-17 1 views
1

Remarqué un comportement étrange qui a commencé après le passage de Java 7 à Java 8 (serveur HotSpot 64 bits) sur Red Hat Linux. Le problème se produit pour un utilisateur particulier, dont les travaux s'exécutent généralement par lots et qui ne peuvent pas se connecter à une invite de connexion. Chaque fois qu'une commande telle que "java -jar hello.jar" est exécutée par cet utilisateur, un fichier binaire de 32 Ko avec un nom de fichier numérique (tel que 18362 ou 24339) est créé dans le répertoire en cours.Pourquoi Java 8 génère-t-il un fichier nommé numériquement dans le répertoire courant?

Les premières phrases lisibles à partir de l'un des fichiers numériques ressemblent à ce qui suit:

[email protected]_sync_ContendedLockAttempts8J0sun.rt._sync_FutileWakeups0J (sun.rt._sync_Parks @ J8sun.rt._sync_EmptyNotifications8J0sun.rt._sync_Notifications8J0sun.rt._sync_SlowEnter8J0sun.rt._sync_SlowExit8J0sun.rt._sync_SlowNotify8J0sun.rt._sync_SlowNotifyAll8J0sun.rt._sync_FailedSpins @ J8sun.rt._sync_SuccessfulSpins8J0sun.rt._sync_PrivateA8J0sun.rt._sync_PrivateB @ J8sun.rt._sync_MonInCirculation8J0sun. rt._sync_MonScavenged8J0sun.rt._sync_MonExtant

Nous avons maintenant plus de 6 000 fichiers de 32 Ko avec un nume ric filename dans le répertoire à partir duquel la commande "java" est lancée.

Ceci est sur un serveur de production. Nous n'avons pas le même problème sur un serveur de développement. Cependant, l'utilisateur en question a la possibilité de se connecter au serveur de développement (disons avec putty) - alors que l'utilisateur ne peut pas le faire sur le serveur de production.

Je voudrais savoir ce qui provoque la création de tous ces fichiers et comment l'empêcher.

+0

il serait plus facile de répondre si nous sauriez ce fait le fichier jar en question ne fait – eis

+2

Je soupçonne que ce sont des décharges ou des traces. L'utilisateur signale-t-il des échecs d'application? – EJP

+0

Peu importe quel fichier jar est exécuté; il génère un nouveau fichier numéroté dans tous les cas (pour cet utilisateur). Le "hello.jar" mentionné simplement imprime "Bonjour tout le monde!". En outre, les exécutions de jar fonctionnent bien sans échec. – user5692647

Répondre

0

La recherche sur un couple de symboles dans la ligne "lisible" semble pointer vers hsperfdata artefacts; voir this Github hsperfdata parser project. Ils sont très susceptibles d'être retirés après les sorties java.

Remarque: Si ce sont hsperfdata artefacts, les nombres sont des identificateurs de processus. Vous pouvez les avoir sur le système de développement dans les répertoires temporaires habituels.

(hypothèse originale que les fichiers restants pourrait être des artefacts de fichiers de classe extraites du fichier JAR supprimé.)

+0

pouvez-vous m'expliquer le concept de «fichiers de classe temporaires»? Jamais entendu parler d'une telle chose. – eis

+1

pourquoi java extrait le fichier .jar dans les fichiers? Ce n'est pas comme ça que java fonctionne habituellement. Les fichiers Jar sont lus directement et les classes sont chargées en mémoire, pas sauvegardées sur le disque. Les enregistrer sur le disque n'a pas beaucoup de sens pour moi, et je n'en ai pas entendu parler auparavant (et j'ai été dans la scène java pendant un certain temps) – eis

+1

Ceci n'est pas une hypothèse probable. Il n'y a rien dans le fichier qui ressemble à un fichier .class à distance, et Java n'a pas besoin d'extraire les fichiers de classe dans les fichiers locaux, mais si c'est le cas, il doit les placer dans des fichiers nommés d'après la classe. – EJP