# File.deleteOnExit()



## takidoso (3. Februar 2009)

Hallo und Halli,
in einer Anwendung, die durch eine Datei prüft, ob sie selbst läuft, wird diese, ich nenne das mal Indikationsdatei, *zyklisch* neu geschrieben, um sicher zu gehen, dass sie nicht von außerhalb gelöscht wurde.
Das ganze passiert in der Anwendung durch folgende Routine

```
static void writeRunningFile() throws Exception
{
        File f = new File("appl.running");
        FileWriter w = new FileWriter(f);
        w.write("application is running since "+DATE_FORMAT.format(START_TIME_STAMP));
        w.flush();
        w.close();
        f.deleteOnExit();
}
```
Dazu eine Frage... Ist es hier unbedenklich, dass jedesmal ein neues File-Object erschaffen und mit deleteOnExit "markiert" wird?
Oder sollte man vorsichtshalber lieber ein einzelnes File-Objekt z.B. als Klassenobjekt definieren, welches dann auch nur einmal markiert wird.
Ich hatte mal im File-SourceCode geschaut, aber die letzte Mehtode, auf die ich bezogen auf die Markierung traf, war abstrakt. Insofern bin ich mir nicht 100% sicher, ob die File-Objekte dann doch irgendwie gehalten werden würden. Anderseits müssten solche Routinen meiner Ansicht nach idiotensicher sein, dass man nicht in eine deratige Falle reinläuft. Am sinvollsten, solte hier tatsächlich nur der Pfad von der JVM gemerkt werden, aber ist das tatsächlich so?

mit neugierigen Grüßen

Takidoso


----------



## Thomas Darimont (3. Februar 2009)

Hallo,

das File Objekt wird hierbei IMHO nicht gemerkt. Das FileHandle wird in einer Liste eingetragen die dann beim exit der JVM zum löschen der entsprechenden Files verwendet wird.

Außerdem die beste und einfachste Möglichkeit das genau zu überprüfen ist ein heap memory dump. -> Am einfachsten mit Visual VM.

Außerdem ... je nach JVM Version kann man sich mit vielen deleteOnExit ein übles memory leak einheimsen:
http://www.tutorials.de/forum/java/233570-ubler-jdk-bug-file-deleteonexit.html

Ob dieser Bug in der jeweiligen Version besteht sieht man am besten in dem man sich den von der JVM native vebrauchten Speicher anschaut (Windows -> Taskmanager)

Gruß Tom


----------

