Java concurrent programming and scalability (2)

Java concurrent programming and scalability (2)
Blocking

Non-competing synchronization can be fully processed in the JVM. Competing synchronization may require the intervention of the operating system to increase overhead. When the lock is in competition, the thread that fails the competition will be blocked. When implementing blocking behavior, JVM can adopt spin wait, that is, continuously trying to get the lock through the loop. Until successful. You can also use the operating system to suspend a blocked thread. The efficiency of these two methods depends on the overhead of context switching and the time needed to wait before the lock is obtained successfully. If the wait time is short, the spin wait method is used. If the wait time is long, the operating system is suspended. Some JVMs will choose between the two based on the analysis data of the historical wait time, but most JVMs only suspend the thread while waiting for the lock.

Reduce lock Competition

In concurrent programs, the major threat to scalability is the exclusive resource lock.

There are two factors that will affect the possibility of competition in the lock: the lock request frequency, the lock holding time. If the product of the two is small, most lock acquisition operations will not compete.

Therefore, there are three ways to reduce the lock contention process:

Reduce lock hold time. Decrease the frequency of lock requests. Use exclusive locks with coordination mechanisms that allow higher concurrency. Narrow the lock range

public class AttributeStore{private final Map
 
   attributes=new HashMap
  
   ();public synchronized boolean userLocationMatches(String name,String regexp){String key="user."+name+".location";String location=attributes.get(key);if (location==null) return false;elsereturn Pattern.matches(regexp, location);}}
  
 

For example, the userLocation method in the above class holds a lock in the execution process of the entire method, and the actual operation to ensure synchronization is only String location = attributes. get (key); this line of code. Therefore, most of the holding time is a waste.

The modification is as follows. You only need to add a built-in lock to the operation that requires the lock. The lock holding time is greatly reduced to improve scalability. In addition, you can use ConcurrentHashMap to further improve its scalability.

public class AttributeStore{private final Map
 
   attributes=new HashMap
  
   ();public  boolean userLocationMatches(String name,String regexp){String key="user."+name+".location";synchronized (this) {String location=attributes.get(key);}if (location==null) return false;elsereturn Pattern.matches(regexp, location);}}
  
 

Reduce lock Granularity

As mentioned earlier, the request frequency for reducing locks can be achieved through lock decomposition and lock segmentation. Multiple independent locks are used in these technologies to protect independent state variables. For example, we added the synchronized keyword to every method. However, they do not access one domain. So there is no need to restrict the state variables when protecting a domain.

import java.util.Set;public class ServerStatus {private final Set
 
   users;private final Set
  
    queries;public ServerStatus(Set
   
     users, Set
    
      queries) {super();this.users = users;this.queries = queries;}public synchronized void addUser(String u) {users.add(u);}public synchronized void addQuery(String u) {queries.add(u);}public synchronized void removeUser(String u) {users.remove(u);}public synchronized void removeQuery(String q) {queries.remove(q);}}
    
   
  
 

Improved lock Decomposition Technology

import java.util.Set;public class ServerStatus {private final Set
 
   users;private final Set
  
    queries;public ServerStatus(Set
   
     users, Set
    
      queries) {super();this.users = users;this.queries = queries;}public void addUser(String u) {synchronized (users) {users.add(u);}}public void addQuery(String u) {synchronized (queries) {queries.add(u);}}public void removeUser(String u) {synchronized (users) {users.remove(u);}}public void removeQuery(String q) {synchronized (queries) {queries.remove(q);}}}
    
   
  
 

Lock Segmentation

In some cases, the lock decomposition technology can be further extended to decompose locks on a group of independent objects. This situation is called lock segmentation.

For example, an array containing 16 locks is used in the ConcurrentHashMap implementation. Each lock protects all hash buckets from 1 out of 16. To achieve better concurrency.

The disadvantage of lock segmentation is that it is more difficult and costly to obtain multiple locks to achieve exclusive access than to use a single lock. For example, if ConcurrentHashMap needs to expand the ing range and re-calculate the hash value of the key value to be distributed to a larger bucket set, it needs to obtain all the locks in the segment set.

public class StripedMap {private static final int N_LOCKS = 16;private final Node[] buckets;private final Object[] lockes;public StripedMap(int num) {super();this.buckets = new Node[num];this.lockes = new Object[N_LOCKS];for (Object lock : lockes) {lock = new Object();}}private final int hash(Object key) {return Math.abs(key.hashCode() % buckets.length);}public Object get(Object key) {int hash = hash(key);synchronized (lockes[hash % N_LOCKS]) {for (Node m = buckets[hash]; m != null; m = m.next) {if (m.key.equals(key)) {return m.Value;}}}return null;}public void clear() {for (int i = 0; i < buckets.length; i++) {synchronized (lockes[i % N_LOCKS]) {buckets[i] = null;}}}}