Je recherche une classe similaire à ThreadLocal qui fonctionnerait sur des groupes de fil au lieu de threads.
S'il n'y a pas une telle classe (dans une bibliothèque open source) Comment le mettriez-vous? Une meilleure idée que d'avoir des groupes de fil dans la faiblesse de la faiblesse?
Je mettant en place un cadre de débogage réglable dans le temps d'exécution avec divers paramètres dans des contextes globaux, périphériques et par fils. Comme un exemple très simple, vous pouvez avoir une instruction de reporting: et spécifier que l'entrée de journal avec cette catégorie spécifique ne sera affichée que lorsqu'elle sera appelée par un thread dans le groupe de Threads Servicing requêtes de réseau.
3 Réponses :
La dernière fois que j'ai examiné la mise en œuvre (il y a quelques années environ) Les locaux de fil ont été implémentés comme une simple table de hachage indexée par l'ID de thread. Rien de fantaisie et de kilomètres de l'efficacité de C ++.
Vous pouvez faire la même chose et utiliser l'objet Groupe de thread en tant que clé de votre propre Tableau de hachage locaux de groupe.
Même (Sun) 1.2 a été mis à jour pour ne pas le faire. C'est très inefficace.
Oui, je sais que c'était il y a longtemps.
Je pense que c'est maintenant une table de hachage à l'intérieur de l'instance de thread, indexée par un objet ThreadLocal. Cela supprime la surcharge de synchronisation, une table de hachage privée par fil.
à l'aide de [ Pour améliorer les performances, notez que threadgroup est rarement utilisé, donc il n'y a pas de support de plate-forme.
faible / identité / concurrent ] hashmap thread ne change pas threadgroup . Par conséquent, cache la valeur avec un threadlocal (remplacement initialvalue ). ThreadLocal a de bonnes performances (une douzaine de cycles par obtenez ).
+1, pour les problèmes de performance. Savez-vous si dans Nowadays Java API soutient nativement cette fonctionnalité?
Je stockerais un support de valeur dans un fil local et l'initialisez-le au même support de valeur pour toutes les threades du même groupe.
ThreadGroupLocal<String> groupLocal = new ThreadGroupLocal<String>();
groupLocal.setValue("foo");
//...
String foo = groupLocal.getValue();
Pourquoi n'avez-vous pas généralisé la valeur titulaire? Et pourquoi l'avez-vous fait étendre ThreadLocal? L'utilisation de ThreadLocal
Bons points, ils méritent d'être envisagés. J'ai écrit ce code pressé comme preuve de concept, alors s'il vous plaît examiner (et testez-vous !!!) il a précédé avant de l'utiliser dans la production. (PS: Je me rappelle maintenant pourquoi la valeur titulaire n'est pas générée, car elles sont stockées dans une carte de hachage statique qui dégénérerait au vous devez faire de toute façon. )
+1, ce que je cherchais. Savez-vous si dans Nowadays Java API soutient nativement cette fonctionnalité?
@Deamcrash Je n'ai pas utilisé Java depuis.
(Remarque, si vous le faites dans un contexte avec le code mobile, vous devez traiter avec des sous-classes malveillantes de threadgroup , et vous ne souhaitez pas fuir lorsqu'un threadgroup devenir inaccessible. Vous pouvez également vouloir que le threadgroup soit capable de devenir inaccessible même lorsqu'il est accessible par ses propres valeurs Threadgrouplocal , qui est amusant.)
Pour des clartés, vous voudrez peut-être lancer des exemples d'utilisation. Aussi pourquoi / comment voulez-vous faire cela.
@Kevin: Il suffit d'ajouter une motivation et un exemple simple.