Programación Concurrente Java verificación volátil no puede garantizar la atomicidad
Por Series aprendizaje, Kaige ha introducido tres características principales de volátiles. 1: 2 para asegurar la visibilidad: no garantiza la atomicidad 3: garantía de la orden. Entonces, ¿cómo verificar la visibilidad de la misma? En este artículo se Kaige (Kaige Java: kaigejava) será demostrada por código volátil demuestra por qué no puede garantizar operaciones atómicas comparten variables.
Vamos a dar un ejemplo de la vida real:
Mediodía a la cafetería Dafan, suponiendo que muy, muy hambriento, carne de necesidad y dos preferencial más un arroz. Si la cantina Dafan tía llamada que un plato cuando interrumpido por otras personas, a otras personas Dafan, y luego dar la vuelta y le das Dafan. Solo tiene que elegir una carne y dos de arroz vegetariano además de un proceso de acabado se vio interrumpido cuatro veces tardan hasta 30 minutos. Uno piensa en sus propios sentimientos. Usted no se va loco, a fuera de control! De hecho, si usted ordena de la tía para dar de terminar una comida este proceso, observando la ejecución de un subproceso de un ordenador, entonces se llega a sus comidas a la carta de este proceso es un completo y no puede ser interrumpido este es el llamado atómica. Si se interrumpe varias veces, y luego pensar en su salud mental, ya sabes, si el resultado del programa se interrumpió en el curso de.
operación atómica se define:
Las denominadas operaciones atómicas se enhebra el funcionamiento de la variable una vez iniciado, se extenderá hasta el final. La mediación no es por otras razones para cambiar a otro hilo. El funcionamiento es indivisible, se completa antes de la ejecución no es interrumpida por otras tareas o eventos. Una pluralidad de operación o las operaciones se llevan a cabo ya sea éxito o fracasan ejecución (atomicidad puede entenderse conjuntamente con la base de datos).
¿Cómo demostrar la modificación de las variables compartidas volátil no puede garantizar la atomicidad de la misma?
escenarios de simulación:
Compartido número variable volátil int = 0; número ++ realizar operaciones. Varias llamadas utilizar varios subprocesos. Mira el uso del número modificado volátil en si los resultados después del final de la aplicación de los resultados esperados.
Estábamos acostumbrados a ejecutar 10 hilos 100 veces, 50 hilos de ejecución y 50 hilos 1000 para realizar un millón de veces para ver los resultados.
Echemos un vistazo a las variables se modifican con volatil
Echemos un vistazo en el interior del hilo principal:
El número de veces que el número de subprocesos que se ejecutan por encima de nuestras necesidades nos fijamos en los resultados reales de funcionamiento y los resultados esperados:
Estábamos acostumbrados a ejecutar 10 hilos 100 veces, 50 veces, y un hilo de ejecución 1000 50 hilos para ejecutar un millón de veces
El número de hilos |
ejecuciones |
número esperado resultados |
Los resultados reales de operación |
10 |
100 |
10*100=1000 |
1000 |
50 |
1000 |
五万 |
49297 |
200 |
1000 |
二十万 |
194181 |
50 |
1000000 |
5千万 |
7246921 |
从上面表格中我们可以看到，即时共享变量用volatile修饰了。但是随着线程数量或者执行次数的增加，实际运行结果与预期结果相差越来越大。如果预期结果和运行结果一致则说明保证了原子性，但是从结果来看不是这样的。从而证明了volatile的第二个特性：不能保证原子性。
为什么从i++的运行结果上就能看出不保证原子性呢？
我们来分析：
正常来说200个线程,每个线程执行了1000次。最后应该输出的是：200*1000=20000.二十万。但是实际结果却不是二十万次。那说明了什么呢？请看下图：
说明:
主内存中有共享变量number的值是0，现在有4个CPU带着4个线程都从主内存中copy变量到自己的工作区。这个是CPU1先竞争到然后再线程1的工作区中执行了number++.执行后将number的值更新成了1，写回到主内存中了。这个时候正要或者正在通知其他CPU主内存中的number值变化了。CPU2和CPU3都收到通知了，将自己工作区的变量置为无效，重新从主内存获取到number=1的值。这个时候CPU4执行的也快，在还没有收到CPU1的通知的时候，就将自己运行后的number++的值也写回到了主内存中。其实这个时候，cpu1线程1的操作还在进行中，但是因为cpu4线程4的操作打断了线程1的操作。第一轮运行结果应该是4，但是因为线程4把线程1执行打断了，将线程1执行结果覆盖了。所以实际执行后的效果有可能是3或者2但是不可能是4.
从上分析结果，我们更能理解到volatile修饰的共享变量不能保证原子性了。因为有可能被其他线程打断执行。
怎么解决原子性问题呢？可以使用juc包下的atomic包下的对象就可以了。
Volatile的有序性证明，欢迎学习下一篇：《Java并发编程之验证volatile指令重排-理论篇》
欢迎关注凯哥公众号：凯哥Java(kaigejava)
