There are several ways to handle concurrent access to shared resources in Java:
Synchronized methods: A synchronized method in Java is a method that can be accessed by only one thread at a time. This can be useful for ensuring that shared resources are not accessed simultaneously by multiple threads.
Synchronized blocks: A synchronized block in Java is a block of code that is surrounded by a synchronized keyword. This ensures that only one thread at a time can access the code within the block, thereby ensuring that shared resources are not accessed simultaneously by multiple threads.
Reentrant locks: A reentrant lock is a type of lock that allows the same thread to re-acquire the lock even if it already holds the lock. Reentrant locks can be used to synchronize access to shared resources in a more flexible manner than synchronized methods or blocks.
Atomic variables: An atomic variable is a type of variable that provides atomic operations that are automatically synchronized by the JVM. This makes it easy to handle concurrent access to shared resources in a thread-safe manner.
Read-write locks: A read-write lock is a type of lock that allows multiple threads to read a shared resource simultaneously, but only one thread can write to the shared resource at a time. This can be useful for optimizing concurrent access to shared resources.
Synchronized methods
In this example, the deposit(), withdraw(), and getBalance() methods are all synchronized. This means that only one thread can execute one of these methods at a time. This is important in a multithreaded environment because it prevents two threads from accessing and potentially modifying the balance variable at the same time, which could lead to unexpected and incorrect results.
The synchronized the keyword is used to mark a method as synchronized. When a thread tries to access a synchronized method, it must first acquire a lock on the object to that the method belongs to. If another thread already holds the lock, the second thread will block and wait until the lock is released.
Note that in this example, the BankAccount object itself is used as the lock. This means that if multiple threads are accessing the same BankAccount object, they will be forced to execute the synchronized methods one at a time. If you need more fine-grained control over synchronization, you can use other objects as locks by using the synchronized block syntax.
Read-write locks
import java.util.HashMap; import java.util.Map; import java.util.concurrent.locks.ReadWriteLock; import java.util.concurrent.locks.ReentrantReadWriteLock; public class ReadWriteMap<K, V> { private final Map<K, V> map = new HashMap<>(); private final ReadWriteLock lock = new ReentrantReadWriteLock(); public V put(K key, V value) { lock.writeLock().lock(); try { return map.put(key, value); } finally { lock.writeLock().unlock(); } } public V get(K key) { lock.readLock().lock(); try { return map.get(key); } finally { lock.readLock().unlock(); } } }
This example ReadWriteMap is a custom implementation of a map that uses ReadWriteLock to allow multiple readers to access the map simultaneously while ensuring that writes are performed exclusively.
The ReadWriteLock is created by instantiating a ReentrantReadWriteLock. This implementation allows for reentrant locking, which means that a thread can acquire the lock multiple times in a row without blocking itself.
The put() the method uses the write lock to ensure that no other thread is modifying the map while a value is being inserted. The get() method uses the read lock to allow multiple threads to access the map simultaneously, as long as no thread is currently writing to it.
Note that the lock is released using a finally block to ensure that the lock is always released, even if an exception is thrown while the lock is held. This is important to prevent deadlocks and other synchronization issues.
Using ReadWriteLock can be a useful technique for improving performance in situations where multiple threads need to access a shared resource that can be read concurrently, but writes must be performed exclusively.

No comments:
Post a Comment