Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Hallo, ich habe ein programm geschrieben das mit einer Schleife das char-Array vollständig am bildschirm ausgibt, der Inhalt des arrays zeichen ist "Lerne Java". Jetzt muss ich die Frage beantworten ob ich in dem array zeichen "Java lernen" einspeichern kann. Geht das oder nicht? Und dann soll ich noch sagen wie viel Speicherplatz das array belegt. Und der Lehrer will jetzt das ich eine Rechnung angebe, wie berechne ich das?
I have an ArrayList<Obj> and I wish to know how much memory it is using. The Obj is variant so, it is not as easy as multiply the number of elements in the array per the size of an object.
It's the capacity of the java.util.ArrayList multiplied by the reference size (4 bytes on 32bit, 8bytes on 64bit) + [Object header + one int and one references].
It's the capacity of the java.util.ArrayList multiplied by the reference size (4 bytes on 32bit, 8bytes on 64bit) + [Object header + one int and one references].
package Uebung5;
public class aufgabe1a {
public static void main(String[] args) {
char [] zeichen={'L','e','r','n','e',' ','J','a','v','a' };
for(int i=0; i<zeichen.length; i++){
System.out.println(zeichen[i]);
}
}
}
das ist das Programm, und dann kommt die Frage
(b) Wäre es auch möglich den Text „Java lernen“ in dem Array zeichen zu speichern?
und
(c) Wie viel Speicherplatz belegt dieses Array?
ich weiss nicht genau was er meint aber dann kommt Fügen sie eine Rechnung ein.
Ich hatte dich nicht gemeint, sondern den TE. Deine Ausführung stand da noch nicht, als ich es geschrieben hatte, aber ich gebe dir vollkommen Recht, er meinte wohl eher char[]. Und dann heist es einfach nur Zeichen Zählen und mit 2 multiplizieren, da 1 char 2 bytes groß ist.
Dieses bedeutet allerdings auch nicht unbedingt, dass jede Darstellung eines Zeichen 2 Bytes lang ist.
Tatsächlich reservieren viele Codierungen nur 1 Byte für jedes Zeichen.
Wird der Konstruktor wie folgt aufgerufen
Code:
String(byte[])Konstruktor aufrufen
wird standmässig byte[] Codierung verwendet.
Da die Plattform-Standardcodierung normalerweise eine 1-Byte-Codierung wie ISO-8859-1 oder eine Codierung variabler Länge wie UTF-8 ist kann ein Zeichen für 1 Zeichen 1 Byte angenommen werden.
ALLERDINGS, Wenn du diesen Code auf einer Plattform ausführst, UTF-16 oder UTF-32 oder ... als Plattform-Standardcodierung verwendet, erhälst sind es mehr als 1 Bytze pro Zeichen.
Ich glaub darauf wollte @mrBrown mit "Und zusätzlich bedenken, wie groß ein char ist" hinaus.
@jezzy Du siehst es kommt auf die Kodierung an, und dazu hast du dich noch nicht ausgelassen.
Deshalb würde ich persönlich, bei der Lösung dabei schreiben: "Unter der Annahme die Codierung ISO-8859-1 oder UTF-8, betägt der Speicherverbrauch <Anzahl der Zeichen> Bytes"
Ok, ich hab es mir gerade durchgelesen, also das gilt ab Java 9, meiner persönlichen Erfahrung nach arbeiten allerdings noch viele mit Java 8.
Was ich nur nicht so ganz verstehe ist, wie soll ein Flag dabei helfen die Codierung zu verkleinern. Hast du damit schon Erfahrung? Und soweit ich den Text verstanden habe wird pro Zeichen
Naja, bis Java 8 wurden Strings intern immer mit einem char-Array (UTF-16) kodiert -> 2 Bytes/Zeichen. Statt des char-Arrays wird jetzt ein Byte-Array verwendet und die Kodierung angegeben. Lässt sich ein String mit ISO-8859-1 kodieren, wird der intern ab Java 9 auch so abgelegt -> 1 Byte/Zeichen.
Ja das hab ich verstanden, was ich meinte war wie kann durch 1 Bit (das Codeflag) den Zeichenraum z.B. für UTF-16 abdecken? Da UTF-16 ein multilingualer Zeichenstring ist und die Zeichenkodierung von 0000 bis FFFF geht - man denke nur mal an die zig tauschend (für das westliche Auge, teilweise täuschend ähnlichen Zeichen, deshalb so geschrieben) Zeichen aus dem Chinesischen. Das habe ich nicht verstanden.
jep, hast recht, hatte ich dann auch gesehen. Meine Frage ist allerdings noch nicht beantwortet, falls du weist wie es geht: Wie schafft man es einen Zeichenvorraten #0000 - #ffff in 1 Byte abzulegen. (Gerad keine Lust / Zeit (arbeite gerad an meinem Projekt)) danach zu googlen
Man schafft es gar nicht. Bei UTF16 nimmt man ein doppelt so langes Byte-Array und nutzt zwei Bytes pro Zeichen. Bei LATIN kommt man mit einem Byte aus.
Ich hatte dich nicht gemeint, sondern den TE. Deine Ausführung stand da noch nicht, als ich es geschrieben hatte, aber ich gebe dir vollkommen Recht, er meinte wohl eher char[]. Und dann heist es einfach nur Zeichen Zählen und mit 2 multiplizieren, da 1 char 2 bytes groß ist.
Da die Plattform-Standardcodierung normalerweise eine 1-Byte-Codierung wie ISO-8859-1 oder eine Codierung variabler Länge wie UTF-8 ist kann ein Zeichen für 1 Zeichen 1 Byte angenommen werden.
ALLERDINGS, Wenn du diesen Code auf einer Plattform ausführst, UTF-16 oder UTF-32 oder ... als Plattform-Standardcodierung verwendet, erhälst sind es mehr als 1 Bytze pro Zeichen.
Strings in Java sind bis Java 8 immer UTF-16, völlig egal, wie die Plattform-Standardcodierung ist.
Die Standardcodierung ist nur relevant, wenn man einen String aus einem byte-Array erzeugt, dabei wird das byte-Array in ein char-Array umgewandelt.
Geändert hat sich das, wie @mihe7 und @Meniskusschaden erklärt haben, mit Java 9. Das ist dann allerdings nicht als Ganzes eine variable Codierung, sondern entweder eine variable mit UTF-16 (mit 2 oder 4 byte) oder eine feste mit Latin-1 (1 byte, "abgeschnittenes UTF-16") - und auch das hat nichts mit der Plattform-Standardcodierung zu tun.
Und das gilt natürlich alles nur für Strings, nicht für char-Arrays - die bestehen immer aus chars.
Ach dann hatte ich dich falsch verstanden, dachte du hättest geschrieben, das ein multilingual character nur 1 Byte braucht, deshalb hatte mich das schon verwundert und wollte daher wissen, wie DU dieses schaffen willst.
Sry my fail! - war halt noch früh am Morgen, da war ich noch nicht so ganz wach
Ach dann hatte ich dich falsch verstanden, dachte du hättest geschrieben, das ein multilingual character nur 1 Byte braucht, deshalb hatte mich das schon verwundert und wollte daher wissen, wie DU dieses schaffen willst.
Sry my fail! - war halt noch früh am Morgen, da war ich noch nicht so ganz wach
import com.sun.jna.Native;
public class MySize {
public static int sizeInByte(String s) {
return s.toCharArray().length * Native.getNativeSize(char.class) + 150;
}
public static void main(String[] args) {
System.out.println(sizeInByte("Java lernen"));
}
}
"Java lernen" beinhaltet 11 Zeichen, also immer 22 byte, und 100 bis 200 byte werden normalerweise als Array Overhead angenommen. Die euch gestellte Frage ist aber eigentlich recht witzlos, da sie nicht beantwortet werden kann...
Klares Nö, man kann sich glaube ich immer i welche Sonderfälle herauspicken. Das stellt dann nicht den Normalfall dar. Jedenfalls würde ich 34 byte nicht als valide Antwort akzeptieren.
Klares Nö, man kann sich glaube ich immer i welche Sonderfälle herauspicken. Das stellt dann nicht den Normalfall dar. Jedenfalls würde ich 34 byte nicht als valide Antwort akzeptieren.
Man braucht sich gar keine Sonderfälle herauspicken, die Normalfälle kann man sich ziemlich leicht berechnen.
Minimal (32bit-VM, <=4-byte Datentyp): 8 Byte Header + 4 Byte für die Array-Länge = 12 Byte "Overhead"
Maximal (64bit-VM, keine compressed oops, 8-byte Datentyp): 16 Byte Header + 4 Byte für die Array-Länge + 4 Byte Padding = 24 Byte "Overhead"
Falls das zu kompliziert für dich sein sollte oder du trotzdem an "100 bis 200 byte [...] als Array Overhead" festhalten möchtest, darfst du gerne erklären, woher die 200 Byte kommen
Falls das zu kompliziert für dich sein sollte oder du trotzdem an "100 bis 200 byte [...] als Array Overhead" festhalten möchtest, darfst du gerne erklären, woher die 200 Byte kommen
Lol, und du hast in deiner Berechnung das Betriebsystem und die JVM vergessen, also wenn schon dann richtig: etwa 461Mb Array Overhead.
Kein Array ist um 100-200 Byte Größer, nur weil es GC gibt. Die genaue Größe des Array-Objects kann man berechnen, und da gehört irgendein GC-Overhead garantiert nicht mit rein.