Noticed an odd behavior that started after moving from Java 7 to Java 8 (HotSpot 64-Bit Server) on Red Hat Linux. The problem happens for one particular user, whose jobs typically run in batch and who cannot log on at a signon prompt. Each time a command such as "java -jar hello.jar" is run by this user, a 32 KB binary file with a numeric filename (such as 18362 or 24339) is created in the current directory.
The first several readable phrases from one of the numeric files look like the following:
8J0sun.rt._sync_Inflations8J0sun.rt._sync_Deflations@J8sun.rt._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
We now have over 6,000 32 KB files with a numeric filename in the directory from which the "java" command is launched.
This is on a production server. We don't have the same problem on a development server. However, the user in question has the ability to log onto the development server (say with putty) -- whereas the user can't do that on the production server.
I'd like to know what causes the creation of all these files and how to prevent it.
Searching on a couple of the symbols in the "readable" line seems to point to hsperfdata artifacts; see this Github hsperfdata parser project. They are very likely safe to remove after java exits.
Note: If these are hsperfdata artifacts, the numbers are process identifiers. You might have these lying around on the development system in the usual temporary directories.
(Original hypothesis that the leftover files might be class file artifacts extracted from the JAR file removed.)