Discussion :

[mathias52]

Bonsoir,

J'ai un serveur multi-threads : plusieurs threads peuvent avoir besoin de lire ou modifier une liste en même temps...

J'ai mis sa (Maps.java) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
...
List<Characters> characters = new ArrayList<Characters>(15);
...
public List<Characters> getCharacters() {
    return new ArrayList(characters);
}
...

la fonction getCharacters renvoit la liste des personnages sur la map, j'ai aussi des fonctions pour ajouter / retirer un personnage sur la map

Mais je ne sais pas si cette méthode est la bonne :s

Le mieux est de renvoyer une copie de la list ou de synchroniser (et retirer les fonctions pour ajouter et retirer un personnage sur la map ?) ?

(Et j'ai la même chose dans plusieurs autre class :/)

Merci

[paissad]

Essaie de synchroniser ta liste avec ceci http://docs.oracle.com/javase/1.5.0/...java.util.List) ... je ne suis pas convaincu que faire une copie de ta liste soit une bonne chose. La synchronisation est plus convenable.

[thelvin]

Ça dépend de pas mal de choses, mais on ne peut pas parcourir une liste dans un thread et la modifier en même temps dans un autre thread. Or, ça me semble être exactement ce que chercherait à faire l'emploi d'une liste synchronisée.

Quand on veut lire toute la liste, il faut en obtenir une copie non-modifiable, dont la construction est entièrement synchronisée.
Et quand on veut la modifier, il vaut mieux passer par un objet qui s'occupera de le faire en synchronisant la chose correctement. Pas le faire sur la List elle-même qu'on accéderait directement.
En respectant ces deux principes, ce n'est pas la List elle-même qui est synchronisée, mais l'objet qui en gère l'accès.

[paissad]

Oui en effet, c'est un principe que je trouve plus convenable

[mathias52]

L'exemple de http://docs.oracle.com/javase/1.5.0/...java.util.List) est

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
  List list = Collections.synchronizedList(new ArrayList());
      ...
  synchronized(list) {
      Iterator i = list.iterator(); // Must be in synchronized block
      while (i.hasNext())
          foo(i.next());
  }

Pourquoi utiliser une liste synchroniser si on doit quand même utiliser synchronized ? :'o Dans ce cas, autant utiliser directement la liste de départ ? (je n'ais pas trop compris l'exemple de la doc ^^)

En respectant ces deux principes, ce n'est pas la List elle-même qui est synchronisée, mais l'objet qui en gère l'accès.

Donc j'aurait :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
private Object lock = new Object()
 
public void maFonction() {
    synchronized(lock) {
        //Une action sur la liste
    }
}

C'est bien sa ? :')

Ah sinon, pour le serveur, j'utilise Apache mina, j'ai regardé un peu de code et j'ai vu que http://docs.oracle.com/javase/1.5.0/...Executors.html

Lorsque vous utilisez beaucoup de synchronisation, essayez de voir si le modèle d'une file d'attente unique ne convient pas mieux (Executor), cela simplifiera de plus beaucoup votre code...

(Source : http://rom.developpez.com/java-synchronisation/#LVI)
Comment mettre en place la synchronisation si je n'utilise que Executor ? (je ne fait pas de new Thread(...).start()

La synchronisation est quelque chose d'essentiel dans beaucoup de situations. Cependant, elle coûte cher en ressources processeur
...
Évitez les anciennes Collections datant de Java 1.0 (Vector, Hashtable...) qui sont par défaut synchronisées, mais utilisez les nouvelles datant de Java 1.2 (ArrayList, HashMap...) qui ne sont pas synchronisées (meilleures performances). Pour récupérer une vue synchronisée d'une Collection, il suffit de faire Collections.synchronizedCollection(Collection).

Hmm...

Ah aussi, j'utilise return new ArrayList(list); car NetBeans ne voulait pas que je renvoit directement la list (donc j'ai test avec une copie et sa fonctionnait et je voulais savoir si c'était bien ou pas ^^)
Sinon, je peut faire Collections.unmodifiableList(list) mais je ne veut pas lancer une exeption si la list risque d'être modifier :/
(Il y a un autre moyen d'avoir des listes non modifiable sans risque de lancer des exeptions ? :'))

[tchize_]

Pourquoi utiliser une liste synchroniser si on doit quand même utiliser synchronized ? :'o Dans ce cas, autant utiliser directement la liste de départ ? (je n'ais pas trop compris l'exemple de la doc ^^)

Non, la liste synchronizée garantit l'exclusivité lors de chaque opération. Parcourir la liste avec un iterator, c'est plusieurs opérations. Il faut créer l'iterator (1), faire un ou plusieurs appels à next (2), faire un ou plusieurs appels à remove(3). Si tu ne veux pas qu'on puisse modifier la liste pendant ce temps, il faut utiliser le même verrou qu'utilisent add(), get(), clear(), remove(), etc. A savoir la liste elle-même.
Si ta liste n'était pas synchronizée, en plus de devoir mettre le bloc pour parcourir avec l'iterateur, tu devrais aussi faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
synchronized(list){
 list.add(element);
}
synchronized(list){
  list.get(0);
}

etc.

[mathias52]

D'accord :')
Donc si la list est synchroniser, je peut faire directement get / add / remove sans synchronized (list) { ... } ?

Lorsque vous utilisez beaucoup de synchronisation, essayez de voir si le modèle d'une file d'attente unique ne convient pas mieux (Executor), cela simplifiera de plus beaucoup votre code...

(http://rom.developpez.com/java-synchronisation/#LVI)
Comme Apache mina utiliser Executor et que je ne créer pas de thread a la main (new Thread(...).start(), un seul thread peut lire a la fois la liste ou une thread peut s'arrêter pendant la lecture de la liste ? (c'est un peu domage si le thread s'arrête pendant la lecture mais bon )

[hwoarang]

Utiliser une liste "synchronized" garanti que les operations de bases soient synchronizees (ajout, suppression, lecture d'un element).

Le probleme, c'est que la plupart du temps, on va vouloir obtenir tous les elements de la liste pour en faire quelque chose. C'est à dire un foreach.
Et la, ca pose probleme puisqu'on va faire un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int i = 0;
while(i < maListe.size())
{
 MaClasse c = maListe.get(i);
c.monTraitement();
i++;
}

Le probleme de ce code, c'est que si pendant son execution un element est supprimé de la liste, on peut avoir un acces hors tableau.
Imaginons une liste avec 1 element.
Comme maListe.size() == 1, on entre dans la boucle. Ensuite, imaginons un changement de thread qui supprime l'element de la liste. On rechange de thread et on revient à notre thread initial qui fait : MaClasse c = maListe.get(i); Le probleme, c'est que maintenant, la liste est vide et donc cet appel va generer une exception. D'ou la necessité de proteger tout le bloc qui parcours une liste qui peut etre utilisée par plusieurs threads...

[deathness]

Je rajouterai que du coup il va falloir faire assez attention de ce que tu vas faire dans ces blocs, cela peut te dégrader un max tes perfs.