Dateien direkt hintereinander schreiben, Dateiname

[Xyz1]

Guten Tag

Es werden direkt hintereinander Dateien geschrieben, der Dateiname lautet (1 <= i <= 3) :

        File file = new File(i + "_" + System.currentTimeMillis() + ".jpg");
        System.out.println("file = " + file);

das Problem dabei ist, das bei Window die Timerauflösung bei 16ms und bei Linux die Timerauflösung bei 1ms liegt, AAABER:
das Schreiben einer Datei geschieht so schnell, das es vorkommen kann, das die alte Datei überschrieben wird.
Wie verhindere ich das?

Desweiteren wartet das Programm zwischendurch 30 - 90 Sek., währenddessen sollte der GC aktiv werden. Reicht es, den GC vor

Thread.sleep(time);

anzustoßen?

Danke fürs lesen

 

[kneitzel]

Also Du kannst die Zeit zwischenspeichern. Wenn die Zeit in der Variablen <= der aktuellen Zeit ist, dann erhöhst du die um 1, ansonsten weist Du die Zeit der Variablen zu. Dann nutzt Du die Variable einfach.

Wieso genau willst Du den GC anwerfen? Sicher, dass dies notwendig ist? Aber ja, wenn Du das wirklich machen willst, dann ist ein System.gc() Aufruf dafür denkbar. Aber: Der Aufruf triggert den GC nicht nur sondern der Aufruf blockiert, bis der GC durch ist. Also wenn die Wartezeit fest definiert ist, dann sehe ich zwei Probleme:
a) Du musst evtl. die Laufzeit vom GC von der Wartezeit abziehen.
b) Wenn der GC sehr lange braucht oder deine Wartezeit zu gering ist, dann könnte die Wartezeit länger sein.

Generell halte ich dies für problematisch. Wenn der GC die Ausführung stört, dann hast Du evtl. ein generelles Problem für das man evtl. andere Lösungen finden muss (bis hin zur Nutzung anderer Lösung, falls halt eine RT Applikation benötigt wird).
Aber wenn es nur eine "softe" Anforderung ist, dann mag es das Verhalten etwas optimieren, aber ich bezweifle derzeit etwas, dass dies viel bringen wird. Da wäre evtl. der Code eher auf mögliche Optimierungen diesbezüglich zu untersuchen. Evtl. lässt sich an den Algorithmen noch etwas drehen. (Aber genauso gut kann es auch kaum noch Optimierungsmöglichkeiten geben.)

 

[InfectedBytes]

bezüglich des überschreibens, du könntest entweder vorher prüfen, ob die datei bereits existiert und dann ggf. einen anderen namen wählen oder du könntest es mal mit System.nanoTime() probieren.

 

[Xyz1]

Achso, System.gc() blockiert, wusste ich nicht... Aber würd in die Wartezeit einberechnet werden.
1) Mehrere Dateien werden hintereinander geschrieben.
2) Das Programm wartet danach mit .sleep(), währendessen sollte eigentlich GC aktiv/aktiviert werden.
3) Vielleicht warte ich nach dem Erstellen Dateinamen einfach ein paar Millisekunden..

 

[mrBrown]

Zu 1.
System.gc() kann auch direkt zurückkehren, ohne das irgendetwas passiert ist. Das hängt von der JVM-Implementation ab, bei einigen kann man den Aufruf auch ausschalten.
Best Practice ist, den nie manuell anzustoßen, sondern allein die JVM darüber entscheiden zu lassen.

Zu 3.
Winkend warten würde ich persönlich nicht in jedem Fall, sondern abhängig vom Zweck des Speicherns.
Sinnvoller könnte es z.B. sein, den letzten timestamp zu speichern, und nur wenn der aktuelle anders ist, das Bild zu sichern. Hängt aber vom Kontext ab...
Mehr Infos könnten da hilfreich sein.

 

[Xyz1]

Ach ich Dummie, ich hab es schon herausgefunden:



mit write:

        File file;
        do {
            file = new File(i + "_" + System.currentTimeMillis() + ".jpg");
        } while (file.exists());
        System.out.println("file = " + file);
        // write...

und main:

        init();
        do {
            run();
            System.gc();
        } while (sleep(start, stop)); // schläft und zieht GC von der Wartezeit ab, false wenn interrupted
        clearBufferFull();

Bis dann.... (Thema sei gelöst)

 

[mrBrown]

Ach ich Dummie, ich hab es schon herausgefunden:

mit write:

        File file;
        do {
            file = new File(i + "_" + System.currentTimeMillis() + ".jpg");
        } while (file.exists());
        System.out.println("file = " + file);
        // write...

Das erstellt allerdings die Datei immer noch neu, wenn sie schon existiert...

und main:

init();
        do {
            run();
            System.gc();
        } while (sleep(start, stop)); // schläft und zieht GC von der Wartezeit ab, false wenn interrupted
        clearBufferFull();

Wie schon gesagt, System.gc() manuell aufrufen ist Bad Practice und sollte es nötig sein, stimmt vermutlich irgendwas am Programm überhaupt nicht...
Die JVM-Implementation des GC würde vermutlich sowieso innerhalb des Thread.sleep() starten, einfach weil da die Auslastung am geringsten ist, wird dabei aber (üblicherweise) wesentlich effizienter sein, als der manuelle Aufruf.

 

[Xyz1]

Wie schon gesagt, System.gc() manuell aufrufen ist Bad Practice und sollte es nötig sein, stimmt vermutlich irgendwas am Programm überhaupt nicht...

Nanana, das Programm funktioniert. Ich wollte den GC aber etwas steuern.

würde
vermutlich
üblicherweise
...

klingt wie einfach mal ins Blaue geraten.

 

[mrBrown]

Nanana, das Programm funktioniert. Ich wollte den GC aber etwas steuern.

würde
vermutlich
üblicherweise
...

klingt wie einfach mal ins Blaue geraten.

Das ist nicht mehr ins Blaue geraten, als die erhofften Auswirkungen von System.gc()
Und das es funktioniert, schließt nicht aus, dass irgendetwas nicht stimmt...

Die JVM garantiert dir nicht mal, dass der Aufruf überhaupt irgendetwas tut.
Wenn er etwas tut, kann der manuelle Aufruf auch durchaus mal schlechtere Auswirkungen auf die Performance haben, als der automatische. Hängt von JVM, GC, deinem Programm und dem Rechner worauf es läuft ab...

 

[kneitzel]

Ich würde bei solchen Dingen empfehlen, einfach einmal etwas mehr zu recherchieren. Bezüglich Aufruf des GC gibt es genug Informationen im Netz. Du hast bezüglich des Aufrufs vom gc von mindestens zwei Usern Hinweise bekommen. Du kannst diese gerne ignorieren - aber diese Antworten von wegen "mal ins Blaue geraten" empfinde zumindest ich als unverschämt. Ich werde nicht für Dich google nutzen um Dir entsprechende Links mit Begründungen zu suchen (da du die vermutlich ehh nicht lesen würdest) noch werde ich lange Begründungen hier schreiben (da dann sonst wieder ein TL DR von Dir kommen würde).

Also wäre meine Empfehlung an Dich hier jetzt kurz und knapp: Üb einmal, selbst Hintergründe zu recherchieren. Das ist für die Softwareentwicklung aus meiner Sicht existenziell.

 

[Xyz1]

unverschämt

unverschämt ist doch die Unterstellung, mein Programm würd überhaupt nicht funktionieren. Desweiteren hab ich meinen Beitrag bereits entschärft.

also ist der Aufruf ein kann oder sollte, aber kein muss? Nicht mehr habt ihr geschrieben.

 

[kneitzel]

"Stimmt etwas am Programm nicht" heißt doch nicht, dass ein Programm nicht funktioniert.

Es kann aus meiner Sicht sehr viel nicht an einem Programm stimmen. Unabhängig davon kann ein Programm fehlerfrei laufen und die gewünschte Ausgabe liefern.

Und die Aussage war "Bad Practice", was soviel heißt wie: Das sollte man nicht machen es sei denn, man hat einen sehr guten Grund dafür und andere Alternativen, die sich sonst so anbieten, funktionieren bei Dir nicht.

Fragen wir einfach einmal anders: Wieso willst Du den Garbage Collector explizit laufen lassen? Das machst Du doch nicht ohne Grund. Ich könnte jetzt wieder mit Clean Code kommen - da gibt es ein Prinzip, das KISS heisst. Keep It Simple, Stupid: Also halte Sachen einfach. Mache nichts, was es unnötig verkompliziert. Und mach keine Sachen, die einfach unnötig sind.

 

[Xyz1]

Das ist ja so als wenn ich zum Arzt gehe, und dann sage, stimmt ja überhaupt nicht, ihre Diagnose...

Wieso willst Du den Garbage Collector explizit laufen lassen?

Die JVM läuft in diesem Fall auf einem Server und darf dort nur das absolute Minimum an Ressourcen benötigen.

 

[kneitzel]

Wenn Du Vorgaben hast, wie viel Speicher maximal belegt werden darf, dann solltest Du das bei dem Aufruf der JVM mitgeben. Die JVM ist bezüglich vieler Punkte optimiert und da kannst Du sehr wenig dran schrauben. Der Aufruf des GC wird den Speicherverbrauch aus Sicht des Servers nicht unbedingt reduzieren. Hintergrund hierfür ist, dass der Server den JVM Prozess sieht. Der belegt einen gewissen Speicher. Dieser Speicher wird dann intern weiter verwaltet durch die JVM. Unabhängig davon, ob dieser Speicher innerhalb der JVM als "frei" oder "belegt" angesehen wird: Der Speicher ist in Nutzung aus Sicht des Systems.

Der JVM klar zu sagen, was verwendet werden darf, ist wichtig, damit die internen Prozesse wissen, was Sache ist. Der GC wird nicht groß aktiv, wenn er meint, dass kein Bedarf da ist. Ich habe mich mit der Implementation des GCs in der JVM bisher nicht beschäftigt, aber typische Implementation der Garbage Collection haben halt mehrere "Stufen" und gewisse Dinge werden halt nur dann geprüft, wenn dies unbedingt notwendig scheint. Ist halt alles mit Aufwand verbunden.

Das Vorgehen ist bei sowas immer mehrstufig:
- Applikation ohne Optimierungen erstellen. (Klar entwickelt man sauber und achtet so auch auf Ressourcen!)
- Testen - erfüllt die Applikation die Anforderungen?
- Wenn nicht: Ursachen prüfen! Wo wird z.B. Speicher verbraucht? Kann man da eingreifen?
Ein Aufruf des Garbage Collectors kommt mir eigentlich nicht so schnell in den Sinn. Da sind dann eher Dinge wichtig wie effektivere Speichernutzung. Hier kann z.B. teilweise die Wiederverwendung von Instanzen eine Möglichkeit sein. Dadurch, dass nicht ständig Instanzen auf Ihre Löschung warten, nimmt man Last vom GC und entspannt so auch die Speichernutzung.

Das aber nur als kurze Anregungen von meiner Seite.

 

[Xyz1]

Okay, dann sage ich konkret, um was es geht:

ich hab eine ArrayList<Deque<byte[]>> list.

Alle 30 Sek. wird die Deque um ein byte[] erweitert. Wenn die Deque 3 byte[] enthält, werden die ersten beiden geschrieben und der Buffer somit geleert.

Das ist doch der "ideale" Zeitpunkt, um mal System.gc() aufzurufen.

import java.io.*;
import java.net.*;
import java.util.*;

/**
 * @author
 */
public class MyClazz {

    private static ArrayList<LinkedList<byte[]>> list;
    private static final String[] strings = new String[]{
        /* ... */
    };

    public static void main(String[] args) throws IOException {
        final long start = /* ... */;
        final long stop = /* ... */;
        System.out.println(/* ... */ + " Min.");
        init();
        do {
            run();
            System.gc();
        } while (sleep(start, stop));
        clearBufferFull();
    }

    private static void clearBuffer() throws IOException {
        for (int i = 0; i < list.size(); i++) {
            if (list.get(i).size() >= 3) {
                while (list.get(i).size() > 1) {
                    write(i, list.get(i).removeFirst());
                }
            }
        }
    }

    private static void clearBufferFull() throws IOException {
        for (int i = 0; i < list.size(); i++) {
            while (!list.get(i).isEmpty()) {
                write(i, list.get(i).removeFirst());
            }
        }
    }

    private static void init() {
        list = new ArrayList<LinkedList<byte[]>>();
        for (String string : strings) {
            list.add(new LinkedList<byte[]>());
        }
    }

    private static boolean notEquals(int i, byte[] ba) {
        if (ba == null || ba.length == 0) {
            return false;
        }
        for (byte[] get : list.get(i)) {
            if (Arrays.equals(ba, get)) {
                return false;
            }
        }
        return true;
    }

    private static void read(int i) {
        byte[] ba = read(strings[i]);
        if (notEquals(i, ba)) {
            list.get(i).add(ba);
        }
    }

    private static byte[] read(String string) {
        byte[] ba = null;
        /* ... */
        return ba;
    }

    private static void run() throws IOException {
        for (int i = 0; i < list.size(); i++) {
            read(i);
        }
        clearBuffer(); /* könnte auch in main() stehen */
    }

    private static boolean sleep(long start, long stop) {
        /* schläft 30 Sek. - benötigte Laufzeit */
        return true;
    }

    private static void write(int i, byte[] ba) throws IOException {
        /* ... */
    }
}

 

[mrBrown]

Ressourcenschonend meint auch, wenig CPU-Last, und je mehr Garbage, desto besserer Effizienz des GC. Also ist dabei Performancemäßig nicht jedes mal wenn Daten da sind Garbage collecten besser, als alle 30sek.
Außerdem erreicht man durch System.gc() nicht unbedingt wenig RAM-Verbrauch, die JVM reserviert sich so viel, wie sie meint zu brauchen (oder durch Optionen vorgegeben), und gibt den nicht zwingend nach System.gc() frei.

uU braucht dein Programm also mehrere GB Ram, nutzt aber nur ein paar MB, und das sehr ineffizient, weil ständig aufgeräumt wird, nur um mal zwei Gründe anzuführen, warum das schlecht sein kann...

Bei deinen byte[] würde ich vom Kontext her auf Bilddaten tippen, die bewegen sich ja eher unteren MB-Bereich, solange man nicht mehrerer 100 auf einmal lädt, dürfte das keinen großen Einfluss auf den Ressourcenverbrauch haben...

Wenn das alle 30sek etwas machen soll, wäre vllt Timer sinnvoller als Thread.sleep()

 

[kneitzel]

Also Deine Logik kann ich nicht nachvollziehen. Hast Du Dich mit der Funktion des GC schon intensiver beschäftigt? Hast Du wenigstens geprüft, ob ein solcher Aufruf notwendig sein könnte? Es gibt ja extra ein Tool Visual VM, mit dem man sehen kann, was so abgeht.

Und es ist ja auch nicht so, dass man da nichts parametrisieren könnte. Ich bezweifle sehr stark, dass es notwendig ist, das zu machen. Aber wenn Du ein Eis essen willst, dann kannst Du hunderte Kilometer fahren. Und dann wirst Du eine Eisdiele finden und uns ganz stolz erzählen, dass man, wenn man ein Eis essen möchte, da mehrere hundert Kilometer fahren kann um ein einfaches Eis zu essen. Und Du kannst auf diese Lösung total stolz sein - zumal du auf dem Weg mehrere Staus umfahren hast und die Fahrt sonst noch optimiert hast. Nur blöd, wenn Dein Startpunkt schon direkt neben einer Eisdiele war und Du da einfach ein leckeres Eis hättest essen können

Und es ist - wie ich wohl schon erwähnt hatte - tatsächlich so, dass es dazu auch viel Dokumentation gibt. Hast Du Dich da mal schlau gemacht und Dinge recherchiert? Eine erste Übersicht könnte man z.B. unter http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/gc01/index.html finden.

Und noch ein kleiner Hinweis: Es gibt einen clear() Aufruf in LinkedList (und anderen Collections). Statt also in einer Schleife alle Werte löschen zu wollen, ist ein clear() Aufruf evtl. einfacher.

 

[Xyz1]

Gibt es eine clean code Richtlinie, wie viele Parameter eine Methode haben sollte, und wie viele Klassenvariablen (global) es geben sollte?

Garbage Collector: Ich werde mich da mal einlesen, in dieser Hinsicht ist das Thema gelöst.

 

[mrBrown]

Sie viele wie nötig, so wenig wie möglich...
Global alles das, was zwingend global ist. Bei globalen Sachen die man aus anderen herleiten kann bzw neu berechnen kann, muss man abwägen, was leichter verständlich und/oder Performanter ist, je nachdem was man will.

Bei Parametern ist es je nach Sinn und Zweck uU nützlich 'nen Wrapper zu nutzen, damit könnte man auch gleich noch validieren.


Zum GC, beim einlesen muss man auf die passende JVM achten, wenn man mehrere unterstützen will, steht man da vor nem großen Berg Doku

 

[kneitzel]

Globale Variablen so, wie es die z.B. in C gibt, gibt es in Java ja nicht. In Java hat jede Variable einen klaren Scope. Globale Variable wäre dann wohl eine public static Variable in einer Klasse.

Generell sollte man sich aber genau überlegen, was man wie braucht. Was in die Richtung geht wäre dann wohl das Singelton Pattern, bei dem es eine statische Instanz der Klasse in der eigentlichen Klasse gibt, ein private Konstruktor und eine static Funktion, die die Instanz erstellt / zurückgibt.

Diese Pattern gibt es nicht ohne Grund, aber man sollte sich schon überlegen, ob sowas wirklich gebraucht wird und ob das Singleton wirklich so von der Logik erzwungen wird oder ob es nur eine Bequemlichkeit ist, die sich ggf. später als schlechtes Design entpuppt. (Mir fällt kein wirkliches Beispiel ein. Aber nehmen wir mal ein Applikationsfenster. Damit Du darauf von allen möglichen Stellen aus zugreifen kannst, machst Du es als Singleton. Aber später soll es evtl. mehrere dieser Fenster geben können. Sprich: Dieses Singleton war dann eine Bequemlichkeit und keine erzwungene Logik.)

 

[mrBrown]

Globale hab ich mal aus Klassenweit aufgefasst...
Nur das, was nötig gilt bei gänzlich globalen natürlich genauso. Je weniger Abhängigkeiten von globalen Dingen, desto besser wartbar, testbar und erweiterbar

 

[kneitzel]

Und schön, dass Du Dich doch etwas für Clean Code interessierst. Daher erlaube ich mir, zwei Referenzen zu nennen:
a) http://www.clean-code-developer.de ist recht schön. Die Webseite war früher mal etwas übersichtlicher finde ich, aber sehr schön finde ich die Stufen. So wird man am Anfang schön geführt.
b) Ein Buch, das mir sehr zugesagt hat: http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882 (Das Buch kostet zwar Geld, aber ich empfehle jedem, das eine oder andere Buch anzuschaffen, so man sich ernsthaft mit der Materie auseinander setzen will. Und es gibt auch Angebote, viele Bücher online zu lesen. Oreilly hat (hatte?) z.B. ein solches Abo - Safari books online oder so ähnlich. Hab ich damals eine Zeit lang genutzt zumal es da schöne Apps für Handy und Tablet gibt (gab?) - habe ich aber schon lange nicht mehr genutzt, da ich komplett auf books24x7 umgestiegen bin, das ich halt vom Arbeitgeber gestellt bekomme. Ich gehe aber mal davon aus, dass es das immer noch geben wird. Und es ist auch so, dass man per Google an PDFs vieler Bücher heran kommt - zwar nicht legal, aber auch eine Methode, in ein Buch hinein zu schnuppern, ehe man es kauft. Fachbücher sind oft nicht preiswert und man will ja kein Geld aus dem Fenster werfen.)

Konrad

 

[Xyz1]

Also ist GC implementierungsspezifisch.

Wegen (globalen) Variablen: Global ist falsch gewählt, ich meinte private Klassenvariablen, Klasse besagt schon etwas über den Scope; z. B. start und stop sind konstante Variablen in main(), refactoren?; einen Index muss ich wohl oder übel mitschleppen, aber was ist mit dem byte[], welches auch über list und Index erreichbar wäre?

Macht doch mal ein Code Review...

 

[mrBrown]

1.
Statt alles static zu haben, ein Objekt der Klasse erstellen.

2. TimerTask extenden, run() hast du ja sowieso schon, und dann, anstatt das manuell in einer Schleife laufen zu lassen, einen Timer starten. Das erübrigt dann die Schleife, sleep(..) und start und stop.

3. notEquals(..) in eine contains(...) umbenennen. not..() als Methodenname ist immer unschön, da dann
!not...() "gesprochen" ein nicht-nicht ist. Außerdem prüft sie ja nicht aus Gleichheit, sondern auf Inhalt.

4. clearBufferFull() mit clean implementieren.

5. ich persönlich würde, soweit möglich, forEach statt des normalen for() nutzen

UU:
Jeweils eine LinkedList<byte[]> und ein String gehören zusammen? Dann in einer Klasse kapseln, und die implementiert dann auch run(), contains(...), die Lesemethoden usw.
Die Main erstellt dann nur noch für jeden String ein Objekt, und startet für jedes den Timer, ist dann auch gleich parallel.

 

[Xyz1]

Muss aber sequenztiell ablaufen! Wäre TimerTask nicht zu viel Overhead (geringe Ressourcen)?

Danke soweit!

 

[mrBrown]

Muss aber sequenztiell ablaufen!

Warum muss es das zwingend? Zumindest in dem bisher geposteten ist nichts erkennbar...

Wäre TimerTask nicht zu viel Overhead (geringe Ressourcen)?

Wenn die Ressourcen so gering sind, dürfte der Overhead durch Java allein schon zu viel sein, und eher etwas in Richtung C/C++ die bessere Wahl sein...
Ich würde bei so geringen Auswirkungen auf die Performance Lesbarkeit über Performance stellen