Vorteil der Verwendung von statischen Variablen in Java

Sagen, ich habe zwei Klassen, wie diese:

class A{  
    private static Random random = new Random();  

    public A(){  
        //Do something.
    }

    public Integer methodGetsCalledQuiteOften(){
        return random.nextInt();
    }
}

class B{  
     private Random random;  

     public A(){  
         random = new Random();
         //Do something.
     }

     public Integer methodGetsCalledQuiteOften(){
         return random.nextInt();
     }
}

In einem Szenario, wo beide von Ihnen mehrfach instanziert und die beiden Klassen' Instanzen' Methode methodGetsCalledQuiteOften aufgerufen wird, eine Menge, ist es real Vorteil/Nachteil (Zeit, Speicher) in eine statische variable, die hält Random() in der Klasse A im Gegensatz zum erstellen einer neuen Random() Objekt in jedem einzelnen Fall, wie in der Klasse B?

Die Anwendung ist multithreaded und ein höheres Maß an Zufälligkeit ist, so dass ich denke, ich werde mit statischen SecureRandom. Wenn, dass wird ein echter Geschwindigkeits-Faktor nach Profilierung, die ich wählen könnte, etwas anderes.

InformationsquelleAutor Nikita | 2010-09-28
  1. 6

    Real Vorteile/Nachteile hängen von real code. In anderen Worten, es hängt davon ab, wie oft ein B erstellt wird verglichen, wie oft die Methode aufgerufen wird, etc. Sollten Sie ein Profil Ihrer Anwendung und sehen, ob es macht einen vernünftigen Unterschied.

    Wird Ein schneller als B? Sicherlich. Aber ob Sie jemals bemerken, hängt von Ihrer Nutzung. Wird weniger Speicher als B? Sicherlich, aber ob Sie interessiert oder nicht hängt davon ab, wie viele Fälle von A/B-Sie halten rund.

    Wirklich die einzige andere überlegung ist Determinismus. Da Sie nicht angeben, den seed für die Random Instanz, nehme ich es Ihnen egal ist, ob Sie Sie reproduzieren die Reihenfolge der zahlen aus dem Zufallsgenerator. Aber es ist erwähnenswert..., wenn Sie ein gemeinsames Random, wird es viel schwieriger zu garantieren, eine bestimmte deterministische Sequenz von zahlen, die für eine Instanz des Ein als ist es mit einem pro-Instanz wie in B.

    • Statische Instanzen bekommt die ganze Zeit laufen. Ist es notwendig, zu stoppen eine zufällige statische Instanz zu einer Zeit, als neue Klasse heißt?
    InformationsquelleAutor Mark Peters
  2. 5

    Nur Nein sagen zu veränderlich statische, m'kay.

    Es ist grauenhaft design. Die üblichen zitierte Folge ist, dass die Testbarkeit ausfällt. Es wird schwierig sein, zu reproduzieren, ohne Neuladen der Klasse. Schlechtes design ist auch schlecht für viele andere Gründe. Nur zu erwähnen, Klassen sollten standardmäßig thread-Agnostiker. Fügen Sie eine mutable statische und Sie sind thread-feindlich - ein schlechter Platz zu sein.

    Erstellen einer neuen Instanz jedes mal scheint verschwenderisch. Obwohl, natürlich, nicht die Optimierung vorzeitig (wenn Sie waren zu optimieren, würden Sie nicht mit java.util.Random). Die ersten sehen Inkrementieren könnte auch Probleme verursachen.

    Der beste Ansatz ist der pass in einer Instanz ("Parametrieren von Oben" oder "mit Konstruktoren richtig"). Dann können Sie testen, zu reproduzieren, zu verspotten, etc. Sie sind effizient und leicht schlagen können, in einer anderen Implementierung.

    • +1 yep yep. Fügen Sie eine mutable statische und Sie sind thread-feindlich
    InformationsquelleAutor Tom Hawtin - tackline
  3. 3

    Wenn Ihr Programm ist single-threaded, Ihre Random sollte ein Schüler (static). Das ist ein bisschen effizienter. Es ist umso wichtiger, wenn mit einem SecureRandom, die eine relativ lange Zeit, um Samen zunächst.

    Wenn mehrere threads am Ende aufrufen methodGetsCalledQuiteOften(), das Problem ist ein bisschen komplizierter. Die Klasse ist thread-sicher, aber der Aufwand erforderlich, um zu schützen, Ihren Zustand während der gleichzeitigen änderungen vielleicht vergleichbar zu machen neue, unabhängige Instanzen Random.

    Ich würde wahrscheinlich stick mit einer static Mitglied, bis ich bemerkte eine Menge von Konflikten zwischen threads für den Zufallszahlengenerator, der wird wahrscheinlich nie passieren.

    • Die ersten SecureRandom wird wahrscheinlich laden ein laden, der security Infrastruktur und dauern ewig. Aber danach sollte es relativ flott, wenn auch nicht so schnell wie die alten, vorhersehbaren java.util.Random.
    InformationsquelleAutor erickson
  4. 2

    Obwohl die Instanziierung der Klasse A ist substantialy (10x) schneller als der Klasse B, dieser ist nur von Bedeutung, wenn Sie dies tun, wie 100.000 mal in der Sekunde.

    Etwa thread-Sicherheit, es ist mein Verständnis, dass .nextInt() basiert auf .next() das sollte thread-sicher. Also multi-threading sollte keine Probleme hier.

    Aber noch wichtiger ist, das Verhalten beider Klassen anders sein kann. Instanzen der Klasse A geben Sie jedem eine etwas zufällige Reihenfolge von zahlen, sondern Instanzen der Klasse B könnte jeder die gleiche Sequenz von 'zufälligen' zahlen (dieses Verhalten kann unterschiedlich sein, die auf verschiedenen Plattformen!). Die Javadoc spec Staaten:

    Wenn zwei Instanzen von Random erstellt werden
    mit dem gleichen Saatgut und der gleichen
    Reihenfolge der Methodenaufrufe ist gemacht für
    jeder, Sie erzeugen und zurückgeben
    identische Sequenzen von zahlen.

    So, wenn die Zufälligkeit ist wichtig, möchten Sie vielleicht zu erwägen, einen einzigartigen Samen, um die Random-Konstruktor oder besser implementieren, die Zufällig mit dem langsameren java.Sicherheit.SecureRandom.

    InformationsquelleAutor Kdeveloper
  5. 2

    Verwenden Sie eine statische variable, wenn die Instanz ist nicht zu erwarten, zu ändern oder, wenn Sie wollen, es zu teilen zwischen den Instanzen.

    private final static int SOME_CONSTANT=1;

    ist ein Beispiel.

    public class USA {
    private final static Map statesOfTheUnion = new HashMap();
    //etc
}

    anderer sein könnte. Im letzteren Fall, erwarten wir nicht, dass die Staaten ändern sich von Instanz zu Instanz. So ist macht keinen Sinn für jede Instanz eine eigene Kopie.

    • Nicht das du meinst zu setzen final und Collections.unmodifiableMap dort?
    • Tolle Idee! 😉 Dies ist nur ein Beispiel. 🙂 Ich verließ die final aus, mehr wie die OP ' s code. Ich erinnere mich nicht, jemals verwenden static ohne final jedoch.
    • Ich fügte hinzu, die finals. Gute Beobachtung.
    InformationsquelleAutor Tony Ennis
  6. 1

    Zugriff auf statische Ressourcen ist nicht thread-sicher. Sie bekommen vielleicht komisch/unvorhersehbare Ergebnisse in einer Multithread-Umgebung.

    • Random-Klasse sorgt für die Synchronisierung intern: Sie können überprüfen Sie die Quellen.
    • Unsynchronisiert Zugriff auf statische Ressourcen kann nicht thread-sicher. Es hängt von der Ressource ab.
    • Zugriff auf Instanz-Felder ist nicht intrinsisch thread-sicher, und Sie vielleicht komisch/unvorhersehbare Ergebnisse in einer Multithread-Umgebung.
    • Ist nicht unberechenbar, was Sie wollen, mit einer zufälligen?</Scherz>
    InformationsquelleAutor hvgotcodes
  7. 1

    Gut, da Random Klasse ergreift die notwendigen Schritte, um sicherzustellen, thread-safety, sehe ich kein problem mit macht es statisch.

    Seit Ihrer Staates umfasst die einzelnen AtomicLong Objekt (8 Byte), es ist keine große Verschwendung von Speicher (es sei denn, Sie planen, erstellen riesige Höhe von B Instanzen).

    So, ich würde sagen, es gibt wenig Unterschied oder so.

    • Wäre nett, wenn Sie setzen, dass in der Dokumentation für Random, statt uns unter Berufung auf die code-Inspektion.
    • Die docs sagen, dass Random ist thread-safe, nur nicht eindeutig: "Die Methode weiter implementiert durch die Klasse Random durch atomar aktualisieren der Samen ..."
    • Guter Punkt, mehr als ein paar standard-Klassen in Java haben dieses problem.
    InformationsquelleAutor Nikita Rybak
  8. 1

    Wenn Sie java.util.Random, beachten Sie, dass es ist ein linear congruential generator mit bekannten Problemen in Zusammenhang mit der Korrelation. Für mich, die eigentliche Frage ist, ob die Anwendung wählen Sie aus einer Reihe oder aus mehreren, mit verschiedenen Samen.

    InformationsquelleAutor trashgod
  9. 0

    In Bezug auf Zeit und Speicher ich kann mir nicht vorstellen, dass es eine große Vorteile (die statische variable wird ein Teil der definition der Klasse, anstatt auf dem heap). Jedoch statische Variablen sind nützlich, wenn Sie wissen, es wird Zugriffe auf das Objekt von mehreren stellen. hvgotcodes richtig ist aber, dass die Verwendung von statischen Ressourcen ist nicht thread-safe. Aber wenn Ihr nur das Lesen der statische Wert dann unter Verwendung von Fäden für Sie in Ordnung ist.

    Werde es speichern Sie von dem pass Verweise auf die eingeleiteten Objekt (A oder B) in andere Objekte, um zu verwenden random

    InformationsquelleAutor Albinoswordfish
  10. -1

    Vorteile von statischen Variablen (die wichtigsten Punkte):

    1. Konstanten können definiert werden, ohne zusätzlichen Speicher (eine für jede Klasse).

    2. Konstanten zugegriffen werden kann, ohne eine Instanziierung der Klasse.

    Vorteile der statischen Methoden:

    Instanz-unabhängig Verhalten kann definiert werden, ohne Angst vor versehentlichen Interaktion mit einer Instanz der Klasse.

    InformationsquelleAutor Raj kumar gajurel
Schreibe einen Kommentar