Object in Datei effizienter lesen / schreiben

[Iron Monkey]

Hi an alle!

Ich benutze mit Java 5 von der Klasse "ObjectOutputStream / ObjectInputStream" die Methode "writeObject( ... ) / readObject()", um die sämtlichen Daten in ArrayList in die Datei zu schreiben bzw. aus der Datei zu lesen!

Es funktioniert alles prima.

Das Problem ist nur, dass die CPU-Auslastung während Datei-Lesen immer ca. bis zu 50 - 52 %!
Das kann ich eigentlich sehr gut nachvollziehen, warum das so ist, aber, um die mittelhohe CPU-Auslastung zu vermeiden, möchte ich gerne von euch hören, wie ich das ganze Objekt aus der Datei, ohne zu blockieren, effektiver auslese!

Hier ist meine Funktion zum Schreiben:

	public static synchronized void writeListToFile( ArrayList list, String file )
	{
		FileOutputStream fos = null;
	    ObjectOutputStream oos = null;
		
	    try
		{
	    	fos = new FileOutputStream( file );
		    oos = new ObjectOutputStream( fos );

		    oos.writeObject( list );
		}
		catch (Exception e) {
			e.printStackTrace();
		}
		finally
		{
			try
			{
			    if( oos != null )
			    {
					oos.flush();
				    oos.close();
				    oos = null;
			    }
			    
			    if( fos != null )
			    {
			    	fos.close();
			    	fos = null;
			    }
			}
			catch (IOException e) {
			}
		}
	}

Hier ist meine Funktion zum Lesen:

	public static synchronized ArrayList readListFromFile( String file )
	{
		if( !isListInFile( file ) )
			return null;
		
		FileInputStream fis = null;
	    ObjectInputStream ois = null;
	    ArrayList list = null;
		
	    try
		{
	    	fis = new FileInputStream( file );
		    ois = new ObjectInputStream( fis );
		    list = (ArrayList) ois.readObject();
		}
		catch (Exception e) {
			e.printStackTrace();
		}
		finally
		{
			try
			{
			    if( ois != null )
			    {
			    	ois.close();
			    	ois = null;
			    }
			    
			    if( fis != null )
			    {
			    	fis.close();
			    	fis = null;
			    }
			}
			catch (IOException e) {
			}
		}
		
		return list;
	}

	public static synchronized boolean isListInFile( String file )
	{
		File f = new File( file );
		
		return (f.length() > 0);
	}

Gruß
Iron Monkey

 

[SlaterB]

solange Java für sich arbeitet sollte die CPU bei 100% stehen, wozu Pausen machen?
alles darunter kommt vielleicht gerade weil das Lesen blockiert,

wie groß ist aber die Liste dass das Lesen eines Objektes so lange dauert, dass du zwischendurch die CPU-Belastung messen kannst?
oder hast du mehrere Dateien zu lesen?

an dem Code kann man nicht viel machen, alternativ eigentlich nur überlegen, die Daten effizienter in einer Textdatei oder Datenbank abzulegen,
ohne den Aufwand der Serialisierung von Objekten

 

[FArt]

wie ich das ganze Objekt aus der Datei, ohne zu blockieren

Wie meinst du das? Du kannst das Lesen asynchron auslagern, dann "blockiert" nichts. Oder suchst du so was wie Channesl, NIO? Was hat die CPU Auslastung von 50% mit blockieren zu tun?

just my 2 cents:
Dein Beispielcode ist schlecht. Wenn du Abläufe darstellen willst, dann lass das try/catch-Gedöns weg.
Wenn du es nicht weglässt, dann verwende es richtig, sonst schaut sich das noch jemand ab: fange nicht Exception, schlucke keine Exceptions, überdecke keine Fehler mit anderen Fehlern (die Streams können null sein, überprüfe das vor dem Schließen), arbeite nach Fehlern nicht einfach weiter, gib nicht null zurück, sondern lieber eine leere Liste, der Methodenname "isListInFile" ist irreführend, ...
... und das mit ein paar Zeilen Code ;-)

 

[Iron Monkey]

@SlaterB
Ich habe nur eine einzige Datei, aus der ich das ganze Objekt auslese.

Das Blockieren kommt von der Methode "readObject". Per TaskManager sehe ich die CPU-Auslastung, die während des Lesens bis zu 50 % hochgeht.

Die Methode "readObject" blockiert solange bis die Daten komplett aus der Datei ausgelesen wurde. Durch dieses Blockieren dachte ich, dass die CPU-Auslastung hochgeht!

Die Datei ist ca. 75 MB groß! Es kommt drauf an, wie viele Daten in ArrayList drin sind und deshalb könnte die Größe der Datei unterschiedlich sein, aber gut, ich muss auch dafür sorgen, dass man bei der großen Datei ohne Probleme mit der CPU-Auslastung anfangen kann, wenn es möglich ist!

@FArt

Was hat die CPU Auslastung von 50% mit blockieren zu tun?

siehe oben den fettgedruckten Satz!

Oder suchst du so was wie Channesl, NIO?

Kann ich mit Channel, NIO, usw. die gesamte ArrayList als Objekt in die Datei schreiben bzw. aus der Datei lesen? Ich glaube nicht! ;-)

Gruß
Iron Monkey

 

[FArt]

Die Methode "readObject" blockiert solange bis die Daten komplett aus der Datei ausgelesen wurde. Durch dieses Blockieren dachte ich, dass die CPU-Auslastung hochgeht!

Falsch gedacht. Die Methode "readObject" blockiert nicht, sie arbeitet, und das kann zu einer CPU Auslastung führen, in dem Fall wohl auch zu Platten I/O. Ein lesender Zugriff auf einen Socket kann blockieren, wenn nämlich die andere Seite keine Daten sendet. Dies nennt man blockieren und das führt nicht dazu, dass die CPU beansprucht wird. Merke: blockieren erhöht nicht die CPU Auslastung.

dass man bei der großen Datei ohne Probleme mit der CPU-Auslastung anfangen kann

Was soll das schon wieder bedeuten?

Vielleicht meinst du, du möchtest das Lesen der Datei mit niedriger Priorität durchführen. Dann lager das Einlesen der Datei in einen Thread mit niedriger Priorität aus.

Schreibe nicht fett sondern drücke dich deutlich aus, das sollte helfen ;-)

 

[Iron Monkey]

... sie arbeitet, und das kann zu einer CPU Auslastung führen, in dem Fall wohl auch zu Platten I/O. ...

OK, FArt, dann habe ich wohl mit den falschen Worten erklärt, aber jetzt hast du ja den richtigen Satz ( siehe oben im Zitat ) geschrieben, was zu meinem Problem führt. Zu dem Wort "Blockieren" habe ich jetzt verstanden.

Genau dieses Problem möchte ich von euch hören bzw. lesen, wie ich das am Besten vermeiden soll.

Vielleicht meinst du, du möchtest das Lesen der Datei mit niedriger Priorität durchführen. Dann lager das Einlesen der Datei in einen Thread mit niedriger Priorität aus.

Das habe ich bereits drin eingebaut! Das einzige Problem ist nur, dass die Datei (z.B. 75 MB) sehr groß ist und beim Einlesen der Datei wird es viel zulange gearbeitet und deshalb geht die CPU-Auslastung für ca. 30 Sekunden bis 60 Sekunden bis zu 52 %! Das kann man doch bestimmt noch effizienter machen oder ist das vielleicht normal?

Ich hoffe, dass du jetzt verstanden hast, was ich meine oder?

Gruß
Iron Monkey

 

[SlaterB]

einfacher wäre immer noch eine Textdatei mit einer einfachen Liste von Daten
3434, 344, 43456, 56, 7676,
oder eine Datenbank, wie gesagt,
statt per Serialisierung für jedes einzelne Objekt 1000 Bytes Daten, mühsam analysiert um daraus wieder Java-Objekte zu schreiben,

ObjectInputStreams sind für 5-50 Objekte gedacht, nicht für 75 MB

 

[Iron Monkey]

einfacher wäre immer noch eine Textdatei mit einer einfachen Liste von Daten
3434, 344, 43456, 56, 7676,
oder eine Datenbank, wie gesagt,
statt per Serialisierung für jedes einzelne Objekt 1000 Bytes Daten, mühsam analysiert um daraus wieder Java-Objekte zu schreiben,

ObjectInputStreams sind für 5-50 Objekte gedacht, nicht für 75 MB

Die Daten sind ja bereits in der Datenbank drin und sie werden durch die Client-Server-Architektur aus der Datenbank geholt. Mein Chef will als Client aber die sämtlichen Daten holen und dann in die JTable füllen. Um die sämtlichen Daten aus der Datenbank zu holen, dauert natürlich eine Weile. Es sind ca. 82.000 Datensätze! Da habe ich mir deswegen gedacht, dass diese Daten am besten in die Datei im lokalen Rechner gespeichert werden soll, um noch schneller zu holen und dann in die Tabelle füllen!

Ich weiss, dass der Vorschlag vom Chef nicht sinnvoll macht, aber da kann ich nichts dagegen tun! Also, muss ich dafür tun!

Jetzt wisst ihr wenigstens mehr, was ich genau vorhabe! ;-)

Gruß
Iron Monkey

 

[SlaterB]

was soll am Vorschlag vom Chef nicht sinnvoll sein?

wenn die Datenbank entfernt liegt, kann es durchaus Sinn machen, die Daten lieber lokal zwischenzuspeichern,
aber was in diesen vorherigen separaten Schritten passiert ist ganz egal,

immer noch bleibt das vorherige bestehen:
bei letzten aktuellen Laden darf kein ObjectStream beteiligt sein,
entweder in eine Textdatei speichern oder wiederum eine (nun lokale) Datenbank

(also das ganze ist von mir auch nur eine Vermutung, die ich beständig wiederhole,
richtig getestet habe ich es nicht)

 

[Iron Monkey]

was soll am Vorschlag vom Chef nicht sinnvoll sein?

wenn die Datenbank entfernt liegt, kann es durchaus Sinn machen, die Daten lieber lokal zwischenzuspeichern,
aber was in diesen vorherigen separaten Schritten passiert ist ganz egal,

Zu dem Vorschlag vom Chef meine ich, dass man die sämtlichen Daten aus der Datenbank holt! Jeder Anwender kann doch nichts mit 82.000 Datensätze anfangen! Das macht für mich keinen Sinn und es hat viele Nachteile, z.B. OutOfMemoryError, usw.! Aber gut, das mit OutOfMemory habe ich bereits gelöst, was nicht leicht war! Es geht aber nicht darum, mehr Speicher erhöhen! ;-)

Und ich habe dem Chef einen Vorschlag gemacht, dass der Client am besten die ersten 500 Datensätze holt und wenn er weitersuchen will, dann kann man mit 2 Button ( "zurück", "vor" ) hin und her klicken! Das macht für mich Sinn. Den Vorschlag nimmt mein Chef nicht an! Da kann ich natürlich nichts machen!

wenn die Datenbank entfernt liegt, kann es durchaus Sinn machen, die Daten lieber lokal zwischenzuspeichern,

Da hast du natürlich recht. Das macht schon Sinn!



Für "lokal zwischenspeichern" habe ich ein Problem, dass die gefüllten Daten der JTable alles in ArrayList gespeichert sind und wie soll ich die ArrayList in TXT-Datei speichern, so dass man beim Lesen der TXT-Datei wieder in die ArrayList gefüllt werden soll? Wie wäre es mit der XML-Datei?

Gruß
Iron Monkey

 

[SlaterB]

na korrekt,
ich weiß nicht welche Daten da drin sind, aber irgend ein Objekttyp wird es ja sein, mit bestimmten Parametern, die du einzeln auflisten musst,
ideal wäre evtl. gleich für JTable optimierte String-Array, da ist der Aufbau der Datei leicht,

du würdest das langsame allgemeine Objekt-Serialisieren durch viel Handarbeit eintauschen, die dafür effizient nur genau das macht was auch wirklich zu tun ist,
zurück liest man eine Textzeile "45;Paul; Lübeck; Monat feuern" als String ein,
musst nach ; splitten, sich mit allerlei sonstigen Problemen rumärgern, ein String[] oder ein Objekt erstellen, in eine neue Liste einfügen usw.,
viel Arbeit, aber 75 MB sollte Java auf diesem Wege in paar Sekunden schaffen (wieder nur vermutet)

> Wie wäre es mit der XML-Datei?

auch gerne, bisschen länger und weniger effizient als txt (besonders wenn du allgemeine Frameworks nutzt),
bei 85000 gleichen Dingen leicht unsinnig,
aber dafür lesbarer und immer noch weitaus besser als Serialisierung


-----

vielleicht geht auch was in die Richtung 'nur 100 der 85000' Einträge laden?
bzw. wieso wird überhaupt lokal gespeichert wenn du alle Einträge gleichzeitig brauchst, für späteren Einsatz im Client?

 

[Landei]

Bei vielen Datenbanken lässt sich eine Replikation einrichten. Lokale Datenbank einrichten, Replikation mit der Hauptdatenbank aufsetzen, Fehler behandeln, wenn mal zwei Nutzer versuchen, am gleichen Datensatz zu wursteln, fertig. Datenbanken können ihre Daten viel schneller abgleichen, als du das mit Java hinbekommst, also versuche nicht, ihren Job zu machen...

 

[Iron Monkey]

Das mit dem Objekttyp ist für mich kein Problem. Da habe ich fest im Griff! ;-)

Super, danke! Genau die Empfehlung von euch wollte ich doch hören! Das mit XML werde ich die Tage mal schauen.

vielleicht geht auch was in die Richtung 'nur 100 der 85000' Einträge laden?
bzw. wieso wird überhaupt lokal gespeichert wenn du alle Einträge gleichzeitig brauchst, für späteren Einsatz im Client?

Ja, zu "'nur 100 der 85000' Einträge laden" habe ich mir selbst auch gedacht, aber das will der Chef nicht! Es ist alles das Chef-Problem! ;-)

Der Client wird ja abgefragt, ob er die Daten aus der Datei holen will oder neu aus der Datenbank! Ja, das ist alles für späteren Einsatz im Client!

Gruß
Iron Monkey

 

[Empire Phoenix]

wie wäre es mit einem lokalen datenbank(server) irgetwas simples aka sql lite? darein apkste dann all die sätze. Wenn die datena us einer SQL datenbank kommen kannste das ganze evtl sogar relativ schnell per database dump befhel holen und direkt da reinkloppen.