He codificado en Java desde la primera versión beta; incluso en ese entonces, los hilos estaban en la parte superior de mi lista de características favoritas. Java fue el primer lenguaje en introducir soporte de subprocesos en el propio lenguaje; fue una decisión controvertida en ese entonces.  En la última década, todos los lenguajes se apresuraron a incluir async/await, e   ... Pero Java zigzagueó en lugar de zagging e introdujo los   . Esta publicación no se trata de eso. incluso Java tenía algún soporte de terceros para eso subprocesos virtuales muy superiores (proyecto Loom)  Creo que es maravilloso y demuestra el poder central de Java. No solo como lengua, sino como cultura. Una cultura de cambios deliberados en lugar de precipitarse en la tendencia de moda.  En esta publicación, quiero volver a visitar las antiguas formas de hacer subprocesos en Java. Estoy acostumbrado a   ,   ,   , etc. Pero ha pasado mucho tiempo desde que fueron el enfoque superior para enhebrar en Java. synchronized wait notify  Soy parte del problema; Todavía estoy acostumbrado a estos enfoques y me resulta difícil acostumbrarme a algunas API que existen desde Java 5. Es una fuerza del hábito. T  Hay muchas API excelentes para trabajar con subprocesos que analizo en los videos aquí, pero quiero hablar sobre bloqueos que son básicos pero importantes.   https://www.youtube.com/watch?v=pUnX8r-6IIo&embedable=true   https://www.youtube.com/watch?v=pOrhJ8o9TT0&embedable=true  Sincronizado vs ReentrantLock  Una renuencia que tuve con dejar sincronizado es que las alternativas no son mucho mejores. La principal motivación para dejarlo hoy es que, en este momento, sincronizado puede desencadenar la fijación de hilos en Loom, lo cual no es ideal.  JDK 21 podría arreglar esto (cuando Loom pase a GA), pero aún tiene sentido dejarlo.  El reemplazo directo de sincronizado es ReentrantLock. Desafortunadamente, ReentrantLock tiene muy pocas ventajas sobre la sincronización, por lo que el beneficio de migrar es dudoso en el mejor de los casos.  De hecho, tiene una gran desventaja; para tener una idea de eso, veamos un ejemplo. Así es como usaríamos sincronizado:   synchronized(LOCK) { // safe code } LOCK.lock(); try { // safe code } finally { LOCK.unlock(); }  La primera desventaja de   es la verbosidad. Necesitamos el bloque try ya que si ocurre una excepción dentro del bloque, el bloqueo permanecerá. Manijas sincronizadas que sin problemas para nosotros. ReentrantLock  Hay un truco que algunas personas usan para envolver la cerradura con   que se ve más o menos así: AutoClosable   public class ClosableLock implements AutoCloseable { private final ReentrantLock lock; public ClosableLock() { this.lock = new ReentrantLock(); } public ClosableLock(boolean fair) { this.lock = new ReentrantLock(fair); } @Override public void close() throws Exception { lock.unlock(); } public ClosableLock lock() { lock.lock(); return this; } public ClosableLock lockInterruptibly() throws InterruptedException { lock.lock(); return this; } public void unlock() { lock.unlock(); } }  Tenga en cuenta que no implemento la interfaz de bloqueo que hubiera sido ideal. Esto se debe a que el método de bloqueo devuelve la implementación de cierre automático en lugar de   . void  Una vez que hagamos eso, podemos escribir un código más conciso como este:   try(LOCK.lock()) { // safe code }  Me gusta la verbosidad reducida, pero este es un concepto problemático ya que probar con recursos está diseñado con el propósito de limpiar y reutilizar bloqueos. Está invocando close, pero volveremos a invocar ese método en el mismo objeto.  Creo que sería bueno ampliar la sintaxis de prueba con recursos para admitir la interfaz de bloqueo. Pero hasta que eso suceda, este podría no ser un truco que valga la pena.  Ventajas de ReentrantLock  La principal razón para usar   es la compatibilidad con Loom. Las otras ventajas son agradables, pero ninguna de ellas es una "función excelente". ReentrantLock  Podemos usarlo entre métodos en lugar de en un bloque continuo. Esta es probablemente una mala idea ya que desea minimizar el área de bloqueo y la falla puede ser un problema. No considero esa característica como una ventaja.  Tiene la opción de equidad. Esto significa que atenderá primero el primer subproceso que se detuvo en un bloqueo. Traté de pensar en un caso de uso realista y no complicado en el que esto sea importante, y estoy dejando espacios en blanco.  Si está escribiendo un programador complejo con muchos subprocesos constantemente en cola en un recurso, puede crear una situación en la que un subproceso se "hambre" ya que siguen llegando otros subprocesos. Pero estas situaciones probablemente se atiendan mejor con otras opciones en el paquete de concurrencia. .  Tal vez me estoy perdiendo algo aquí...    nos permite interrumpir un hilo mientras espera un bloqueo. Esta es una característica interesante, pero nuevamente, es difícil encontrar una situación en la que realmente haga una diferencia. lockInterruptibly()  Si escribe código que debe ser muy receptivo para interrumpir, necesitará usar la API   para obtener esa capacidad. Pero, ¿cuánto tiempo pasa en promedio dentro del método   ? lockInterruptibly() lock()  Hay casos extremos en los que esto probablemente importa, pero no es algo con lo que la mayoría de nosotros nos encontremos, incluso cuando hacemos un código avanzado de subprocesos múltiples.  LeerEscribirReentranteBloquear  Un enfoque mucho mejor es   . La mayoría de los recursos siguen el principio de lecturas frecuentes y pocas operaciones de escritura. Dado que la lectura de una variable es segura para subprocesos, no es necesario un bloqueo a menos que estemos en el proceso de escribir en la variable. ReadWriteReentrantLock  Esto significa que podemos optimizar la lectura hasta el extremo y hacer que las operaciones de escritura sean un poco más lentas.  Suponiendo que este sea su caso de uso, puede crear un código mucho más rápido. Cuando trabajamos con un bloqueo de lectura y escritura, tenemos dos bloqueos; un bloqueo de lectura como podemos ver en la siguiente imagen. Permite múltiples subprocesos y es efectivamente un "gratis para todos".  Una vez que necesitamos escribir en la variable, necesitamos obtener un bloqueo de escritura como podemos ver en la siguiente imagen. Intentamos solicitar el bloqueo de escritura, pero todavía hay subprocesos leyendo de la variable, por lo que debemos esperar.  Una vez que los subprocesos terminen de leerse, toda la lectura se bloqueará y la operación de escritura puede ocurrir desde un solo subproceso solo como se ve en la siguiente imagen. Una vez que liberemos el bloqueo de escritura, volveremos a la situación de "gratis para todos" en la primera imagen.  Este es un patrón poderoso que podemos aprovechar para hacer que las cobranzas sean mucho más rápidas. Una lista sincronizada típica es notablemente lenta. Se sincroniza sobre todas las operaciones, lectura o escritura. Tenemos una CopyOnWriteArrayList que es rápida para leer, pero cualquier escritura es muy lenta.  Suponiendo que pueda evitar la devolución de iteradores de sus métodos, puede encapsular operaciones de lista y usar esta API.  Por ejemplo, en el siguiente código, exponemos la lista de nombres como de solo lectura, pero luego, cuando necesitamos agregar un nombre, usamos el bloqueo de escritura. Esto puede superar fácilmente a las listas   : synchronized   private final ReadWriteLock LOCK = new ReentrantReadWriteLock(); private Collection<String> listOfNames = new ArrayList<>(); public void addName(String name) { LOCK.writeLock().lock(); try { listOfNames.add(name); } finally { LOCK.writeLock().unlock(); } } public boolean isInList(String name) { LOCK.readLock().lock(); try { return listOfNames.contains(name); } finally { LOCK.readLock().unlock(); } }  Cerradura Estampada  Lo primero que debemos entender sobre   es que no es reentrante. Digamos que tenemos este bloque: StampedLock   synchronized void methodA() { // … methodB(); // … } synchronized void methodB() { // … }  Esto funcionará. Dado que sincronizado es reentrante. Ya mantenemos el candado, por lo que entrar en   desde   no se bloqueará. Esto también funciona con ReentrantLock, suponiendo que usemos el mismo bloqueo o el mismo objeto sincronizado. methodB() methodA()    devuelve un sello que usamos para liberar el bloqueo. Por eso, tiene algunos límites. Pero sigue siendo muy rápido y potente. También incluye un sello de lectura y escritura que podemos usar para proteger un recurso compartido. StampedLock  Pero a diferencia de   nos permite actualizar el bloqueo. ¿Por qué tendríamos que hacer eso? ReadWriteReentrantLock,  Mire el método   de antes... ¿Qué pasa si lo invoco dos veces con "Shai"? addName()  Sí, podría usar un Conjunto... Pero para el objetivo de este ejercicio, digamos que necesitamos una lista... Podría escribir esa lógica con   : ReadWriteReentrantLock   public void addName(String name) { LOCK.writeLock().lock(); try { if(!listOfNames.contains(name)) { listOfNames.add(name); } } finally { LOCK.writeLock().unlock(); } }  Esto apesta. "Pagué" por un bloqueo de escritura solo para verificar   en algunos casos (suponiendo que haya muchos duplicados). Podemos llamar   antes de obtener el bloqueo de escritura. Entonces haríamos: contains() isInList(name)  Coge el candado de lectura  Liberar el bloqueo de lectura  Agarra el bloqueo de escritura  Liberar el bloqueo de escritura  En ambos casos de acaparamiento, es posible que estemos en cola y que no valga la pena la molestia adicional.  Con   , podemos actualizar el bloqueo de lectura a un bloqueo de escritura y hacer el cambio en el lugar si es necesario como tal: StampedLock   public void addName(String name) { long stamp = LOCK.readLock(); try { if(!listOfNames.contains(name)) { long writeLock = LOCK.tryConvertToWriteLock(stamp); if(writeLock == 0) { throw new IllegalStateException(); } listOfNames.add(name); } } finally { LOCK.unlock(stamp); } }  Es una potente optimización para estos casos.  Finalmente  Cubro muchos temas similares en la serie de videos anterior; échale un vistazo y déjame saber lo que piensas.  A menudo busco las colecciones sincronizadas sin pensarlo dos veces. Eso puede ser razonable a veces, pero para la mayoría, probablemente sea subóptimo. Si dedicamos un poco de tiempo a las primitivas relacionadas con subprocesos, podemos mejorar significativamente nuestro rendimiento.  Esto es especialmente cierto cuando se trata de Loom, donde la disputa subyacente es mucho más delicada. Imagine escalar operaciones de lectura en 1 millón de subprocesos simultáneos... En esos casos, la importancia de reducir la contención de bloqueo es mucho mayor.  Podría pensar, ¿por qué las colecciones   no pueden usar   o incluso   ? synchronized ReadWriteReentrantLock StampedLock  Esto es problemático ya que el área de superficie de la API es tan grande que es difícil optimizarla para un caso de uso genérico. Ahí es donde el control sobre las primitivas de bajo nivel puede marcar la diferencia entre un alto rendimiento y un código de bloqueo.

Shai is a Developer Advocate at Lightrun, where he's busy explaining why hotfixing just to add a log line needs to be a thing of the past. He is also a JavaOne rockstar that has been developing software professionally for ~30 years, a published author, an open-source hacker (founder and long-time maintainer of Codename One) , an experienced Java trainer and a public speaker. When he's not in front of his machine you can find him making food for his two kids or doing Yoga with his wife (well, at least attempting to).

2021 - HackerNoon Contributor of the Year - DEBUGGING

2022 - HackerNoon Contributor of the Year - Coding Skills

2022 - HackerNoon Contributor of the Year - Debugging

2022 - HackerNoon Contributor of the Year - Java

2022 - HackerNoon Contributor of the Year - Monitoring

2022 - HackerNoon Contributor of the Year - Software Testing

Debug Agent

Buy My Book

Learn on my YouTube Channel

Read My Stories

Newsletter

Follow me on Twitter

Author/DevRel/Entrepreneur/Hacker

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Una guía para volver a aprender las primitivas de subprocesos de Java

Una guía para volver a aprender las primitivas de subprocesos de Java

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Una breve introducción a la teoría del cerebro de Boltzmann

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

Una breve introducción a la teoría del cerebro de Boltzmann

Aumente su productividad con estas 18 herramientas para desarrolladores 🚀🔥

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps