Was sind die verschiedenen Möglichkeiten, die wir brechen ein singleton-pattern in Java

Was sind die verschiedenen Möglichkeiten, die wir brechen ein singleton-pattern in Java.
Ich kenne einen Weg, d.h. wenn wir synchronisieren nicht die Methode im singleton -, dann können wir es schaffen, mehr als eine Instanz der Klasse. Also die Synchronisation angewendet wird. Gibt es eine Möglichkeit zu brechen singleton java-Klasse.

public class Singleton {
    private static Singleton singleInstance;

    private Singleton() {
    }

    public static Singleton getSingleInstance() {
        if (singleInstance == null) {
            synchronized (Singleton.class) {
                if (singleInstance == null) {
                    singleInstance = new Singleton();
                }
            }
        }
        return singleInstance;
    }
}

eigentlich ist dieser code falsch ist, der nicht initialisierten Singleton zugeordnet werden können singleInstance, bevor Konstruktor beendet
entfernt ee-tag, da gibt es nichts, ee-spezifische über diese Frage
du meinst private static Singleton singleInstance= new Singleton() ?
Nein, ich meine, dass die zugewiesenen Objekt gespeichert ist singleInstance vor dem Konstruktor ausgeführt wird, bedeutet dies, dass ein anderer thread Zugriff auf den nicht initialisierten singleton-was zu Fehlern führen kann
Gotcha 🙂

InformationsquelleAutor Harsha_2012 | 2013-12-06

java singleton

Beginnend mit dem angegebenen code, "Double-Checked-Locking" können brocken bei einigen Umwelt,
Bei der Ausführung auf einem system mit dem Symantec-JIT, es funktioniert nicht. Insbesondere die Symantec-JIT-kompiliert

singletons[i].reference = new Singleton();

folgt (beachten Sie, dass der Symantec-JIT-mit einem Handgriff-basierten Objekt-allocation system).

0206106A   mov         eax,0F97E78h
0206106F   call        01F6B210                  ; allocate space for
                                                 ; Singleton, return result in eax
02061074   mov         dword ptr [ebp],eax       ; EBP is &singletons[i].reference 
                                                ; store the unconstructed object here.
02061077   mov         ecx,dword ptr [eax]       ; dereference the handle to
                                                 ; get the raw pointer
02061079   mov         dword ptr [ecx],100h      ; Next 4 lines are
0206107F   mov         dword ptr [ecx+4],200h    ; Singleton's inlined constructor
02061086   mov         dword ptr [ecx+8],400h
0206108D   mov         dword ptr [ecx+0Ch],0F84030h

Wie Sie sehen können, ist die Zuordnung zu singletons[i].Referenz durchgeführt wird, bevor der Konstruktor Singleton aufgerufen. Dies ist völlig legal im Rahmen der bestehenden Java-memory-Modell, und auch legal, in C und C++ (da keiner von Ihnen eine Speicher-Modell).

http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Abgesehen davon, dass

Es kann brechen, wenn die Klasse Serializable
Es kann brechen, wenn seine " Clonable`
Können Sie brechen durch Reflection (glaube ich)
kann es zu brechen ff mehreren classloadern geladen werden, die Klasse

*Wie lösen Sie regelbrechern?

Es ist viel sicherer, zu tun, eifrig Initialisierung
Um zu verhindern, dass Deserialisieren zu erstellen neues Objekt
Sie können überschreiben readResolve() Methode in Ihrer Klasse und Ausnahme auslösen
Um zu verhindern, dass das Klonen,
Sie können overrride clone() und werfen CloneNotSupported Ausnahme
Zu entrinnen reflektierende instantion, können wir fügen Sie im Konstruktor und Ausnahme auslösen.

Beispiel

public class Singleton {

    private static final Singleton INSTANCE = new Singleton();

    private Singleton() {
        //Check if we already have an instance
        if (INSTANCE != null) {
           throw new IllegalStateException("Singleton" +
             " instance already created.");
        }
    }
    public static final Singleton getInstance() {
        return INSTANCE;
    }
    private Object readResolve() throws ObjectStreamException         {
            return INSTANCE;
    }
    private Object writeReplace() throws ObjectStreamException {
            return INSTANCE;
    }
    public Object clone() throws CloneNotSupportedException {
        //return INSTANCE
        throw new CloneNotSupportedException();
    }
}

Nachdem alle, würde ich vorschlagen, verwenden Enum als der sicherste Weg für Singleton (Seit java5 der beste Weg, es zu tun, ist die Verwendung eines enum)

public static enum SingletonFactory {
    INSTANCE;
    public static SingletonFactory getInstance() {
        return INSTANCE;
    }
}

Sie können durch eine if(singleInstance!=null)throw new RuntimeError(); im Konstruktor
aktualisierte Antwort 🙂

InformationsquelleAutor Satheesh Cheveri

3

Eigentlich eine sichere version ohne die Notwendigkeit für die Synchronisierung ist die Variante mit einer geschachtelten Klasse Halter:
```
public final class Singleton{

  public static final Singleton getInstance(){
    //no need for synchronization since the classloader guarantees to initialize
    //Holder.INSTANCE exactly once before handing out a reference to it
    return Holder.INSTANCE;
  }
  private Singleton();
  private static class Holder{
    private static final Singleton INSTANCE = new Singleton();
  }
}
```
Anderen sicheren Versionen sind:
- Eifrig Initialisierung
```
public final class Singleton{
    public static final Singleton getInstance(){
        return INSTANCE;
    }
    private Singleton();
    private static final Singleton INSTANCE = new Singleton();
}
```
- Enum Singleton
```
public enum Singleton{
    INSTANCE;
}
```
Alle diese Versionen haben vor-und Nachteile, aber keiner von Ihnen muss explizite Synchronisierung, da Sie alle verlassen sich auf den ClassLoader und der eingebauten Thread-Sicherheit.

Wie die anderen geschrieben haben, können Sie brechen einige dieser Muster durch Deserialisierung. Lesen Sie Effektive Java von Joshua Bloch (Artikel 74 bis 78) über die Verhinderung solcher Angriffe (enum singleton-Muster ist sicher gegen solche Angriffe aus dem Feld).
- oder einfach nur darauf Initialisierung full stop und lassen Sie Klasse-be-Semantik Griff die lazyness
- ja, genau
- können wir mit Hilfe des static-block statt der statischen Klasse ?
- ja, aber dann haben wir eifrig Initialisierung. Aber natürlich ratchet_freaks Kommentar gilt auch hier
InformationsquelleAutor Sean Patrick Floyd
2

Eine Möglichkeit ist die Serialisierung. Wenn Sie nicht implementieren readResolve dann Lesen, ein singleton mit ObjectInputStream.readObject() wird wieder eine neue Instanz dieser singleton.

InformationsquelleAutor Evgeniy Dorofeev
1

AFAIK gibt es zwei Möglichkeiten, es könnte gebrochen werden
- Mithilfe Der Reflektion
- Wann gibt es custom classloadern, die mehr als ein (d.h. der parent class loader).alle singletons, die geladen werden soll durch gemeinsame übergeordnete classloader.
- Können Sie bitte die reflektion code für das brechen singleton ?
- Ich habe gerade gegoogelt, dieser link wird dir helfen - blog.yohanliyanage.com/2009/09/breaking-the-singleton
InformationsquelleAutor Keerthivasan

import java.io.Serializable;

public class Singleton implements Serializable,Cloneable{

private static final long serialVersionUID = 1L;

private static Singleton singleton=null;
private Singleton(){

}

public static Singleton getInstance(){
    if(singleton==null){
        singleton=new Singleton();
    }
    return singleton;   
}

@Override
public Object clone() throws CloneNotSupportedException{
    return super.clone();
}
}

** Singleton-Test **

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.lang.reflect.Constructor;
import java.lang.reflect.InvocationTargetException;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

/***
 * 
 * Ways to break Singleton
 */
public class Main {

private static ObjectInputStream inputStream;

public static void main(String[] args) throws Exception {
    Singleton orginalSingletonObject = Singleton.getInstance();

    /***
     * Singleton is broken by using Reflection
     */
    breakSingletonByReflection(orginalSingletonObject);

    /***
     * By Serialization/De-Serialization break Singleton We need
     * Serialization interface in a class nedds to be serialized like
     * Singleton.java
     */
    breakSingletonByserialization(orginalSingletonObject);

    /***
     * By Cloning break Singleton
     * We need to implement Cloneable interface
     */
    breakSingletonByCloning(orginalSingletonObject);


    /***
     * Break Singleton By thread
     * This scenario is related to multi-threading environment
     * 
     */

    breakSingletonByThreading(orginalSingletonObject);
}

private static void breakSingletonByThreading(Singleton orginalSingletonObject) {

    ExecutorService executorService=Executors.newFixedThreadPool(2);
    /**
     * Run this code snippet after commenting the other code for better understanding
     * Run it repeatly to create a condition when 2 threads enter the method getInstance() of Singleton class at a same time 
     * When 2 threads enter the getInstance method at same time they will get the singleton object as null (private static Singleton singleton in Singleton.java)
     * Then they will create two different objects ( have different hashcode) in this case singleton pattern will break.
     */
    executorService.submit(Main::useSingleton); //JAVA 8 syntax it will get the singleton instance
    executorService.submit(Main::useSingleton);
    executorService.shutdown();
}

public static void useSingleton(){
    Singleton singleton=Singleton.getInstance();
    printSingletonData("By Threading", singleton);

}


private static void breakSingletonByCloning(Singleton orginalSingletonObject) throws CloneNotSupportedException {
    Singleton clonedSingletonObject=(Singleton) orginalSingletonObject.clone();
    printSingletonData("By Cloning", orginalSingletonObject, clonedSingletonObject);
}

private static void breakSingletonByReflection(Singleton orginalsingleton)
        throws ClassNotFoundException, NoSuchMethodException,
        InstantiationException, IllegalAccessException,
        InvocationTargetException {

    Class<?> singletonClass = Class.forName("SingletonTest.Singleton");
    @SuppressWarnings("unchecked")
    Constructor<Singleton> constructor = (Constructor<Singleton>) singletonClass
            .getDeclaredConstructor();
    constructor.setAccessible(true);
    Singleton s = constructor.newInstance();
    printSingletonData("By Reflection", orginalsingleton, s);
}

private static void breakSingletonByserialization(Singleton orginalsingleton)
        throws FileNotFoundException, IOException, ClassNotFoundException {

    /**
     * Serialization
     */
    ObjectOutputStream outputStream = new ObjectOutputStream(new FileOutputStream("E:\\Singleton.ser"));
    outputStream.writeObject(orginalsingleton);
    outputStream.close();

    /**
     * DeSerialization
     */
    inputStream = new ObjectInputStream(new FileInputStream("E:\\Singleton.ser"));

    Singleton deserializeObject = (Singleton) inputStream.readObject();
    deserializeObject.hashCode();
    printSingletonData("By Serialization", orginalsingleton, deserializeObject);


}

public static void printSingletonData(String operationName,
        Singleton orginalsingleton, Singleton reflectionSigletonObject) {

    System.out.println("------------------------------------------");
    System.out.println("New Operation");
    System.out.println(operationName);
    System.out.println("orginal Hashcode=" + orginalsingleton.hashCode());
    System.out.println("New Object hashcode="
            + reflectionSigletonObject.hashCode());
    Boolean value = orginalsingleton.hashCode() != reflectionSigletonObject.hashCode();
    System.out.println("These Object have different hascode. They are two different object Right = "
                    + value);
    System.out.println("As these are different Object this means Singleton Pattern is broken");
}


private static void printSingletonData(String operationName,Singleton singleton) {


    System.out.println("------------------------------------------");
    System.out.println("New Operation");
    System.out.println(operationName);
    System.out.println("Object hashcode="   + singleton.hashCode());

}
}

InformationsquelleAutor Deepak

Klasse cls = Singleton.class;

    Constructor constructor = cls.getDeclaredConstructor();
    constructor.setAccessible(true);

    Singleton singleton = (Singleton) constructor.newInstance();

InformationsquelleAutor Dharma

0

Multithreading ist das größte Problem mit singletons.
Sie können vermeiden, dass durch die Synchronisierung oder Verwendung eifrig Initialisierung.

Andere Möglichkeit wäre die Verwendung von singleton, wo Sie nichts zu suchen hat. Indem Sie das singleton-Muster, das Sie anwenden können, Sie in einer Weise behindert, dass Sie Ihr Programm in späteren Entwicklung. (E. G, das erstellen einer singleton - "Spieler" in einem Spiel, weil Sie davon ausgehen, es ist ein singleplayer-Spiel. Der nächste Schritt in der Entwicklung "add co-op-Funktionalität").

Das singleton-Muster hat es Vorteile, aber verwenden Sie es nicht ohne carefull consideration.

InformationsquelleAutor Dylan Meeus
0

Einen ersten Hinweis: Es wäre besser, in diesem Fall, vor allem für die Lesbarkeit, um die ganze getSingleInstance() { } synchronized:
```
public synchronized static Singleton getSingleInstance() {
    if (singleInstance == null) {
        singleInstance = new Singleton();
    }
    return singleInstance;
}
```
Andere als das, ich glaube nicht, dass es einfach ist, den code zu knacken. Natürlich, wenn Sie hinzufügen rekursive Aufrufe, dann ist es möglich, es zu brechen, wie diese:
- Rufen Sie den Konstruktor einer anderen Klasse innerhalb dieser Singleton's Konstruktor.
- Im Konstruktor der Klasse, versuchen, dies zu erhalten Singleton Instanz.
Aber das ist das einzige, was ich denken kann, und Sie können nicht schützen Sie sich vor, dass in der Singleton Klasse.

InformationsquelleAutor skiwi
0

Synchronisierten Ansatz funktionieren wird, aber wird auch langsam jedem Zugriff auf die singleton-etwas zu schützen, das immer nur passiert, in den ersten Zugriff.

Der einfachste und sicherste Weg ist einfach zu tun, eager initialization, dass ist immer sicherer als Java garantiert, dass alle member-Variablen festgelegt werden, bevor es kann jeder auf Sie zugreifen.
```
public class Singleton {
    private static Singleton singleInstance = new Singleton();

    private Singleton() {
    }

    public static Singleton getSingleInstance() {
        return singleInstance;
    }
}
```
Ihre aktuelle Ansatz ist tatsächlich gebrochen, auch mit Ihr synchronisiert Schleife - denn double-check-locking ist gebrochen. Sie müssen daneben die singleton-variable als volatile wenn du gehst zu verwenden es für double-check-locking denn ansonsten gibt es immer noch Möglichkeiten für threads Zugriff auf eine unvollständig initialisierte Objekt. Sehen http://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java für mehr details.

InformationsquelleAutor Tim B

Angenommen, Sie haben Singleton-Klasse implementiert, die als "SingletonPattern" als unten.
package com.Beispiel.Muster;

public class SingletonPattern
{
  private static SingletonPattern pattern;

  public static SingletonPattern getInstance()
  {
    if (pattern == null)
    {
      synchronized (SingletonPattern.class)
      {
        if (pattern == null)
        {
          pattern = new SingletonPattern();
        }
      }
    }
    return pattern;
  }
}

Jetzt können Sie brechen Sie die Singleton-Verhalten dieser Klasse mit den folgenden Ansatz.

Class c = Class.forName("com.example.pattern.SingletonPattern");
System.out.println((SingltonPattern) c.newInstance());

InformationsquelleAutor Kuldeep Singh

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.