Concurrency Errors in Java
Download as PPTX, PDF3 likes4,636 views
This document discusses concurrency errors in Java and how to avoid them. It begins by defining a concurrency error as the result of incorrect synchronization that can cause issues like race conditions and starvation. It notes that concurrency errors can lead to data corruption, security vulnerabilities, and incorrect behavior. While Java includes synchronization primitives, concurrency is still tricky and errors can occur if the primitives are used incorrectly or without properly designing the concurrency model. The document provides examples of potential concurrency errors and ways to avoid them, such as locking on an appropriate shared object to ensure atomic read/write operations. In the end, it emphasizes the importance of remaining vigilant about concurrency through tools, analysis, and careful design.
Concurrency Errors in Java
- 2. What Is a Concurrency Error? And Why You Should Care About Them
- 3. What Is a Concurrency Error? A concurrency error is the result of incorrect synchronization safeguards in multi-threaded software. Typical concurrency errors include race conditions and starvation.
- 4. Why You Should Care Consequences to users: • Data corruption • Security vulnerabilities • Incorrect behavior • Denial of service Consequences to developers: • Time consuming to find, even with a debugger • Difficult to test for • Can reduce reliability of the testing suite by interrupting test runs
- 5. Java is a modern language with synchronization primitives to enforce safe concurrency models. Does that mean that concurrency errors are easy to avoid in Java? Question:
- 6. Answer: No! The concurrency primitives help you implement a well-designed concurrency model. But: • You still need to design the concurrency model • Concurrency primitives applied incorrectly do not protect you from problems • It’s easy to apply concurrency primitives incorrectly • Bottom line: concurrency is tricky, even in Java!
- 7. Consider this Code Snippet* Note: • msg is read from the session on line 64 • msg is removed from the session on line 71 • This code is not enclosed in a “synchronized” block • Other threads may read/update the session * From an open source project
- 8. Consider this case: 1. You read msg (line 64) 2. Another thread changes the status message 3. You delete the status message (line 71) You just lost the other thread’s status message! Problem: You Might Lose Status Messages in Your App
- 9. To Avoid the Problem: You need to handle the read/delete atomically. Maybe something like this: synchronized(this) { // or add “synchronized” to the method msg = (String)req.getSession().getAttribute(STATUS_MESSAGE); if (msg != null) { // Move pw.printLn() calls outside the sync. block req.getSession().removeAttribute(STATUS_MESSAGE); } } We do an atomic read/delete, so things will work correctly, right? No! (Remember, concurrency is tricky!)
- 10. To Avoid the Problem: You need to handle the read/delete atomically. While holding an appropriate lock synchronized(this) { // or add “synchronized” to the method msg = (String)req.getSession().getAttribute(STATUS_MESSAGE); if (msg != null) { // Move pw.printLn() calls outside the sync. block req.getSession().removeAttribute(STATUS_MESSAGE); } } Because we’re locking on this, other threads will be able to use the session while we do our work—it’s not really atomic! We need to lock on a shared object, like the session, instead. But locking on the session has its own problems! (Remember, concurrency is tricky!)
- 11. To Avoid the Problem: You need to handle the read/delete atomically. While holding an appropriate lock // You need to define session_lock in an appropriate scope // and ensure other threads use that same lock synchronized(session_lock) { msg = (String)req.getSession().getAttribute(STATUS_MESSAGE); if (msg != null) { // Move pw.printLn() calls outside the sync. block req.getSession().removeAttribute(STATUS_MESSAGE); } } By having all threads lock on the same object, you can ensure that the status message is managed safely. It can be challenging to implement the lock in the proper scope—you often have to choose between correctness and performance.
- 12. In Short… 1. Remain vigilant about concurrency errors • Understand how objects are shared between threads • Be certain that you are locking on appropriate objects • Be careful to handle exceptional cases, too! 2. Use tools to identify cases that you miss • Static analysis (often available in IDE, too!) • Dynamic analysis 3. Enjoy the extra time you’ve freed up
- 13. demo http://www.coverity.com/request-a-free-trial.html Want to learn more about how Coverity can help you write better code? Request a free trial:
- 14. Copyright 2013 Coverity, Inc.