Recientemente vi un fragmento de código que usaba un objeto ThreadLocal y mantenía un ConcurrentHashMap dentro de él.¿Hay algún beneficio al colocar un objeto ThreadSafe en un ThreadLocal?
¿Hay alguna lógica/beneficio en esto, o es redundante?
Si la referencia solamente a la HashMap concurrente reside en el ThreadLocal, el HashMap es, obviamente, sólo se hace referencia a partir de un solo hilo. En tal caso, diría que es completamente redundante.
Sin embargo, no es difícil imaginar a alguien "compartir" el mapa hash almacenado localmente con hilos de otros hilos:
ThreadLocal<ConcurrentHashMap<String, String>> tl = ...
// ...
final ConcurrentHashMap<String, String> props = tl.get();
EventQueue.invokeLater(new Runnable() {
public void run() {
props.add(key.getText(), val.getText());
}
});
De hecho. 'ThreadLocal' permite que N hilos tengan N variables independientes; es posible que no se relacionen con los objetos contenidos (no hay ningún requisito de que cada ThreadLocal tenga un objeto diferente y/o único). –
Buen punto - Verificare si hay/hubo tal uso. – RonK
O bien se utiliza ThreadLocal erróneamente, o ConcurrentHashMap erróneamente. La probabilidad de que la combinación tenga sentido es cercana a 0.
esto no es correcto. Hay casos de uso de sonido donde el objeto en un subproceso local es compartido por varios subprocesos. –
Además de lo que dijo @aioobe, considere el caso de InheritableThreadLocal, en el cual el valor de local se pasa de un hilo a cada hilo hijo que crea.
Y como @pst dice, no hay nada que impida que se use el mismo valor en diferentes (no heredables) ThreadLocal s.
En resumen, tiene que hacer un análisis exhaustivo de los locales del hilo, la forma en que se inicializan y la forma en que se utilizan antes de poder concluir con seguridad que no es necesario que sean enhebrables.
@Downvoter - cuidado de explicar? – RonK
hay algunas personas por aquí que solo votan negativamente ... sin ningún comentario ... no permitiría votos sin comentarios ... – Cris