Thread-Safe classe singleton

J'ai écrit ci-dessous classe Singleton. Je ne suis pas sûr de savoir si c'est thread-safe classe singleton ou pas?

public class CassandraAstyanaxConnection {
private static CassandraAstyanaxConnection _instance;
private AstyanaxContext<Keyspace> context;
private Keyspace keyspace;
private ColumnFamily<String, String> emp_cf;
public static synchronized CassandraAstyanaxConnection getInstance() {
if (_instance == null) {
_instance = new CassandraAstyanaxConnection();
}
return _instance;
}
/**
* Creating Cassandra connection using Astyanax client
*
*/
private CassandraAstyanaxConnection() {
context = new AstyanaxContext.Builder()
.forCluster(ModelConstants.CLUSTER)
.forKeyspace(ModelConstants.KEYSPACE)
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
.setDiscoveryType(NodeDiscoveryType.RING_DESCRIBE)
)
.withConnectionPoolConfiguration(new ConnectionPoolConfigurationImpl("MyConnectionPool")
.setPort(9160)
.setMaxConnsPerHost(1)
.setSeeds("127.0.0.1:9160")
)
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
.setCqlVersion("3.0.0")
.setTargetCassandraVersion("1.2"))
.withConnectionPoolMonitor(new CountingConnectionPoolMonitor())
.buildKeyspace(ThriftFamilyFactory.getInstance());
context.start();
keyspace = context.getEntity();
emp_cf = ColumnFamily.newColumnFamily(
ModelConstants.COLUMN_FAMILY, 
StringSerializer.get(), 
StringSerializer.get());
}
/**
* returns the keyspace
* 
* @return
*/
public Keyspace getKeyspace() {
return keyspace;
}
public ColumnFamily<String, String> getEmp_cf() {
return emp_cf;
}
}

Quelqu'un peut-il m'aider? Toute réflexion sur mon ci-dessus classe Singleton sera d'une grande aide.

Code Mis À Jour:-

Je suis en train d'intégrer Bohème suggestion dans mon code. Voici le code mis à jour, j'ai obtenu-

public class CassandraAstyanaxConnection {
private static class ConnectionHolder {
static final CassandraAstyanaxConnection connection = new CassandraAstyanaxConnection();
}
public static CassandraAstyanaxConnection getInstance() {
return ConnectionHolder.connection;
}
/**
* Creating Cassandra connection using Astyanax client
*
*/
private CassandraAstyanaxConnection() {
context = new AstyanaxContext.Builder()
.forCluster(ModelConstants.CLUSTER)
.forKeyspace(ModelConstants.KEYSPACE)
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
.setDiscoveryType(NodeDiscoveryType.RING_DESCRIBE)
)
.withConnectionPoolConfiguration(new ConnectionPoolConfigurationImpl("MyConnectionPool")
.setPort(9160)
.setMaxConnsPerHost(1)
.setSeeds("127.0.0.1:9160")
)
.withAstyanaxConfiguration(new AstyanaxConfigurationImpl()      
.setCqlVersion("3.0.0")
.setTargetCassandraVersion("1.2"))
.withConnectionPoolMonitor(new CountingConnectionPoolMonitor())
.buildKeyspace(ThriftFamilyFactory.getInstance());
context.start();
keyspace = context.getEntity();
emp_cf = ColumnFamily.newColumnFamily(
ModelConstants.COLUMN_FAMILY, 
StringSerializer.get(), 
StringSerializer.get());
}
/**
* returns the keyspace
* 
* @return
*/
public Keyspace getKeyspace() {
return keyspace;
}
public ColumnFamily<String, String> getEmp_cf() {
return emp_cf;
}
}

Quelqu'un peut jeter un oeil et laissez-moi savoir si cette fois je l'ai eu raison ou pas?

Merci pour l'aide.

Oui il c'thread-safe, aussi longtemps que le Keyspace et ColumnFamily classe sont trop. Il n'est pas optimale, cependant, vous allez obtenir beaucoup de contention sur la classe de synchronisation dans getInstance(). Vous devez rechercher la "enum pattern singleton".
voir javarevisited.blogspot.dans/2012/07/... et stackoverflow.com/questions/427902/... et peut-être répondre à votre propre question avec de nouveaux enum version de votre classe ty @eurobur pour le signaler
suffit d'utiliser un enum
stackoverflow.com/questions/70689/...

InformationsquelleAutor arsenal | 2013-04-19

199

Vous êtes à la mise en œuvre de la initialisation modèle où l'instance est créée lors de la première utilisation.

Mais il y a un truc simple qui vous permet de coder un des threads mise en œuvre que n'est pas nécessitent une synchronisation! Il est connu comme le l'Initialisation sur demande du titulaire de l'idiome, et il ressemble à ceci:
```
public class CassandraAstyanaxConnection {
private CassandraAstyanaxConnection(){ }        
private static class Holder {
private static final CassandraAstyanaxConnection INSTANCE = new CassandraAstyanaxConnection();
}
public static CassandraAstyanaxConnection getInstance() {
return Holder.INSTANCE;
}
//rest of class omitted
}
```
Ce code initialise l'instance sur le premier appel de getInstance(), et, surtout, il n'a pas besoin de synchronisation en raison du contrat de la classe loader:
- la classe loader charge des classes qui leur sont accessibles (dans ce cas Holders'accès se fait exclusivement à l'intérieur de la getInstance() méthode)
- quand une classe est chargée, et avant que quiconque puisse l'utiliser, tous les initialiseurs statiques sont garantis d'être exécuté (c'est quand Holder's statique bloc de feux)
- le chargeur de classe a sa propre synchronisation intégré qui font les deux points précités garantie à des threads
C'est un très joli petit truc que j'utilise à chaque fois que j'ai besoin d'initialisation. Vous bénéficiez également de la bonification d'un final exemple, même si c'est créé paresseusement. Notez également comment propre et simple, le code est.

Edit: Vous devez définir tous les constructeurs privés ou protégés. Réglage à vide et le constructeur privé va faire le travail
- pourquoi votre classe à être consulté avant getInstance est appelé? avoir d'autres méthodes statiques?
- ce que je veux dire est que si vous avez un singleton pourquoi voulez-vous exposer d'autres méthodes statiques? et si non, alors pourquoi la classe être initialisé sauf quand quelqu'un a appelé getInstnace?
- Je n'ai pas le préciser (mais j'ai édité pour le faire). La classe dont l'initialisation je parle est statique à l'intérieur de la classe Holder, pas à l'extérieur de la classe CassandraAstyanaxConnection. Cette mise en œuvre ne change pas l'API, sauf à supprimer la synchronized mot clé de getInstance(), améliorant ainsi les performances de l'accès à l'instance.
- "private static intérieure champ statique" -- il y a un nom officiel pour cela, Initialisation sur demande du titulaire / être présentées
- c'est le meilleur impl-dessus de tous. bon une autre classe dans le moteur d'exécution mais ne savent pas comment beaucoup plus de mem, qui prendra alors une case et la synchronisation chaque fois que vous appelez getInstance
- De combien de mémoire peut-elle prendre? Il a juste un champ statique et rien d'autre. Quelques octets au maximum.
- Merci pour la suggestion. Je suis en supposant que c'est la bonne façon de faire pour le singleton thread-safe classe et également après la lecture de divers article sur l'internet aussi, je pense que c'est la bonne façon. J'ai donc mis à jour ma question avec la dernière version du code. Pouvez vous s'il vous plaît prendre un coup d'oeil et laissez-moi savoir si c'est correct ou pas? Merci pour l'aide.
- Votre code est parfait 🙂 Et oui, je crois que ce modèle est le plus propre, plus rapide pattern singleton que nous thread-safe. Vous êtes les bienvenus pour l'aider. Bonne chance avec votre voyage.
- Brian Goetz et coll., Java de la Simultanéité dans la Pratique (2006), 348.
- Que faire si vous avez besoin de passer un paramètre à getInstance()?
- le passage d'un paramètre implique que les différentes instances seront renvoyés en fonction du paramètre, qui est le méthode le patron, pas le pattern singleton.
- pas nécessairement, si la chose que je suis de passage dans le contexte de mon application (Android)
- Que faire si un autre appel est effectué avec un paramètre différent? Si un seul paramètre est destiné à être transmis, puis créer une autre méthode comme static synchronized initialize(MyParam x) qui ne peut être appelé qu'une seule fois, et ont getInstance() retourner l'instance créée en initialize()
- Il est à l'origine des infractions suivantes: Accesseur Génération de Classe - Éviter l'instanciation par les constructeurs privés provenant de l'extérieur du constructeur de la classe.
- que "la violation" ne peut être que d'un peu de style outil de vérification (par exemple checkstyle). Il n'y a rien de mal avec le code; il compile et exécute OK.
- Oui, c'est vrai. Je viens de le mentionner dans le cas où une personne ont le même problème. Je suis encore à essayer de comprendre comment résoudre cette violation.
- À mon humble avis c'est un faux positif et l'outil doit être configuré, ou la ligne marquée, d'ignorer cette instance de la règle. La classe appelant le constructeur est privé intérieur de la classe, qui est part de la classe elle-même. Vous pourriez faire un travail autour de l'aide d'une méthode de fabrique: Dans Holder ne INSTANCE = MyClass.create(); et ajouter private static MyClass create() {return new MyClass();}, mais qui serait de pure forme; fait d'éviter l'arbitraire d'un style à la règle mais en ajoutant pas de valeur réelle. Mieux pour l'ignorer.
- Que faire si une autre instance est créée grâce à la Classe cls = la Classe.forName("com.test.Test"); Object Object = cls.newInstance();
- Aucun code de protection peut être contournée en utilisant la réflexion. L'aide de la réflexion, vous pouvez instancier un Void et muter en une Chaîne de caractères. Cela ne veut pas dire "le code est brisé".
- La Question est à propos de la sécurité des threads du singleton si je suis correct. Et la réponse est sur la façon de créer un Singleton fil en toute sécurité au moment de la création. Il ne garantit pas que l'utilisation du singleton est sur le point d'être thread-safe. En fait OP singleton est aussi valable mise en œuvre il y a quelques temps. Mais la sécu instancié singleton sera un thread-safe singleton seulement si les deux keyspace et emp_cf sont thread-safe (ex. immuable).
- très propre, intelligente façon de faire.
- Merci ... cela mérite plus de votes.
InformationsquelleAutor Bohemian
15

toutes les méthodes ci-dessus sont très initialisation de l'objet. comment à ce sujet. Cela vous aidera à initialiser ur de la classe paresseusement. Vous pouvez avoir un objet lourd et vous ne voulez pas à s'initialiser au démarrage.
```
public class MySinglton { 
private MySinglton (){}
private static volatile MySinglton s;
public static MySinglton getInstance(){
if (s != null ) return s;
synchronized(MySinglton.class){
if (s == null ) {
s = new MySinglton();
}
}
return s;
}
} 
```
- Je ne sais pas si cet article s'applique toujours, mais selon ce qu'il est rompu: cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
- le mot clé volatile conserve 🙂 Le lien que vous avez partagé, il suffit d'aller dans la dernière section. L'une des solution est de faire ur singleton variable volatile.
- cette mise en place a un constructeur public, n'importe qui peut créer autant d'objets qu'elle le souhaite, de sorte qu'il ne peut pas être considéré comme un singleton. Vous laissez le constructeur public par défaut pour échapper à
- ok. une ligne à ajouter ici.. ajouté constructeur privé.
- vous avez raison, mais il est vraiment facile d'omettre volatile mot-clé et dans 99,99% des cas, il faudra encore travailler. À mon humble avis il est préférable d'utiliser d'autres modèles qui requièrent le moins de code (par exemple, enum)
InformationsquelleAutor Mohammad Adnan

Pas, ce n'est pas thread-safe si les valeurs retournées sur le pulbic méthodes sont changeble objets.

À cette classe Thread-safe est un moyen de le changer immuable.

Pour ce faire, vous pouvez changer cette méthode comme ceci:

public Keyspace getKeyspace() {
//make a copy to prevent external user to modified or ensure that Keyspace is immutable, in that case, you don't have to make a copy
return new Keyspace( keyspace );
}
public ColumnFamily<String, String> getEmp_cf() {
//Same principle here. If ColumnFamily is immutable, you don't have to make a copy. If its not, then make a copy
return new ColumnFamily( emp_cf );
}

Dans ce livre Java de la Simultanéité dans la Pratique vous pouvez le voir, le principe de l'immutabilité.

InformationsquelleAutor Jose Renato

2

Comme mentiond dans cet excellent article ici :

La meilleure solution à ce problème est [...] l'utilisation d'un champ statique
```
public class Singelton {
private static final Singelton singleObject = new Singelton();
public Singelton getInstance(){
return singleObject;
}
}
```
- Tu veux dire désireux d'initialisation statique champ final !
InformationsquelleAutor Andro Secy
0

Non, ce n'est pas apparaissent être thread-safe. Il semble que vous il y a mutable données accessibles après l'appel à getInstance, où le verrou aurait été publié.

InformationsquelleAutor Tom Hawtin - tackline

Après java version 1.5, nous pouvons utiliser volatile. Si nous avons utilisé volatils java clé de la paroisse, nous pouvons créer singlton classe avec thread-safe, Parce que la variable d'instance, de partager avec les Autres fil ainsi.

public class SingleWithThreadSafe {
//create an object static referance of SingleWithThreadSafe with volatile
private static volatile SingleWithThreadSafe instance = null;
//if we make the constructor private so that this class cannot be
//instantiated from out side of class
private SingleWithThreadSafe() {
}
//Get only object available
public static SingleWithThreadSafe getInstance() {
if (instance == null) {
instance = new SingleWithThreadSafe();
}
return instance;
}
public void showMessage() {
System.out.println("Hello World!");
}
}

InformationsquelleAutor Thusitha Indunil

-1

Je pense que cela va faire la même chose sans avoir à vérifier par exemple à chaque fois. statique est la même que de vérifier la première fois
```
public class Singl {        
private static Singl _instance;
//other vars        
static{
//synchronized(Singl.class){//do not need
_instance = new Singl();
//}
}
public static Singl getInstance() {
return _instance;
}
private Singl(){
//initizlize
}
}
```
- Je n'ai pas DV, mais il ya quelques questions ici. 1) statique init et synchronisés sont inutiles: Java VM spec garantit la sécurité de simple static Singl _instance = new Singl(); 2) vous n'avez pas indiquer qu'il est désireux d'initialisation, par opposition à un paresseux qui est indiqué dans la question
- ce ne sera pas désireux. il va se passer la première fois que vous appelez getInstance que c'est lorsque la classe est accessible à la première fois. ou tu fais une classe.forname. ty sujet statique de synchronisation.
- il est désireux dans le sens où elle n'est pas contrôlée par getInstance invocations. Penser à elle, vous pouvez innocemment reportez-vous Singl.class et boom! l'initialisation est là, même si vous n'essayez même pas d'invoquer getInstance
InformationsquelleAutor tgkprog

Vous devez vous connecter pour publier un commentaire.