Java Multithreading Performance optimization

Everyone uses multithreading is nothing more than to improve performance, but if the use of multithreading is inappropriate, not only performance improvement is not obvious, and will make the resource consumption greater. Here's a list of points that might cause multi-threading performance issues:

• Dead lock

• Too many serialization

• Excessive lock competition

• Toggle Context

• Memory synchronization

The following separate analysis of the above performance problems

Dead lock

On the deadlock, we learn the operating system when we know its cause and harm, here is not from the principle of the statement, you can read from the following code and diagram of the cause of the deadlock:

[Java] view plaincopy

2. public class Leftrightdeadlock {

4. Private Final Object left = new Object ();

6. Private Final Object right = new Object ();

8. public void LeftRight () {

10. Synchronized (left) {

12. Synchronized (right) {

14. DoSomething ();

16. }

18. }

20. }

22. public void Rightleft () {

24. Synchronized (right) {

26. Synchronized (left) {

28. Dosomethingelse ();

30. }

32. }

34. }

36. }

Ways to prevent and handle deadlocks:

1) Try not to compete for other locks before releasing the lock

Generally can be achieved through the refinement of the synchronization method, only in the real need to protect the shared resources where to take the lock, and release the lock as soon as possible, so as to effectively reduce the synchronization method calls other synchronization methods of the situation

2) Sequential Request lock Resource

If it is not possible to avoid nesting request lock resources, you need to develop a policy to request lock resources, first plan what locks, and then each thread in a sequence to obtain, do not appear in the above example in the different order, so there will be a potential deadlock problem

3) Try a timed lock

Java 5 provides a more flexible locking tool that can be used to explicitly request and release locks. Then you can set a time-out when the lock is requested, and if the lock has not been obtained for more than this time, it will not continue to block but give up the task, the sample code is as follows:

[Java] view plaincopy

2. public boolean trysendonsharedline (String message,

4. Long timeout, timeunit unit)

6. Throws Interruptedexception {

8. Long Nanostolock = Unit.tonanos (timeout)

10. -Estimatednanostosend (message);

12. if (!lock.trylock (Nanostolock, nanoseconds))

14. return false;

16. try {

18. return sendonsharedline (message);

20. } finally {

22. Lock.unlock ();

24. }

26. }

This can effectively break the deadlock condition.

4) Check for deadlocks

The JVM uses thread dump to identify deadlocks by sending a thread dump signal to the JVM through the commands of the operating system, which can be queried for which thread deadlock.

Too many serialization

Multithreading actually wants to do things in parallel, but these things because some dependencies must be serial work, resulting in a lot of serialization, which is actually very limited to the scalability of the system, even if the CPU plus threading, but the performance is not linear growth. There is a Amdahl theorem to illustrate this problem:

Where F is the serialization scale, N is the number of processors, and it is known that the scalability can be maximized only if the serialization is minimized. The key to reduce the serialization is to reduce the lock competition, when many parallel tasks are linked to the acquisition of locks, is the performance of serialization

Excessive lock competition

The danger of too much lock competition is self-evident, then see what ways to reduce the lock competition

1) Reduce the range of locks

This is also mentioned earlier, as far as possible to narrow the scope of lock protection, fast forward and fast, so try not to use the Synchronized keyword directly on the method, but only in the real need of thread security to use the place

2) Reduce the size of the lock

Java 5 provides an explicit lock, which allows for more flexibility in protecting shared variables. The Synchronized keyword (used in the method) is the default to take the entire object as a lock, in fact, many times it is not necessary to use such a large lock, which causes all synchronized of this class to be executed serially. You can use a shared variable that you really need to protect as a lock, or a more granular strategy that is designed to be serialized when it really needs to be serialized, to give an example:

[Java] view plaincopy

2. public class Stripedmap {

4. Synchronization Policy:buckets[n] guarded by locks[n%n_locks]

6. private static final int n_locks = 16;

8. Private final node[] buckets;

10. Private final object[] locks;

12. private static Class Node {...}

14. Public stripedmap (int numbuckets) {

16. Buckets = new Node[numbuckets];

18. Locks = new Object[n_locks];

20. for (int i = 0; i < n_locks; i++)

22. Locks[i] = new Object ();

24. }

26. Private final int hash (Object key) {

28. Return Math.Abs (Key.hashcode ()% buckets.length);

30. }

32. public object get (object key) {

34. int hash = hash (key);

36. Synchronized (locks[hash% n_locks]) {

38. for (Node m = Buckets[hash]; m = null; m = m.next)

40. if (M.key.equals (key))

42. return m.value;

44. }

46. return null;

48. }

50. public void Clear () {

52. for (int i = 0; i < buckets.length; i++) {

54. Synchronized (locks[i% n_locks]) {

56. Buckets[i] = null;

58. }

60. }

62. }

64. ...

66. }

The above example is a hash algorithm to access the value of the corresponding hash value as a lock, so that only the same hash value of the same object access serialization, and not as Hashtable as any object of any operation is serialized.

3) Reduce the reliance on shared resources

Shared resources are the source of competition lock, in the multi-threaded development to minimize the reliance on shared resources, such as Object pool technology should be considered carefully, the new JVM to create new objects to do enough optimization, performance is very good, if the use of object pool not only can not improve the performance, but because of the lock competition to reduce the concurrency of the thread.

4) Replace exclusive lock with read-write separation lock

Java 5 provides a read-write separation lock (Readwritelock) for reading-and-read concurrency, read-and-writes serial, and write-write serial features. This approach further increases concurrency because some scenarios are mostly read, so there is no need to work serially. For specific use of readwritelock you can take a look at the example:

[Java] view plaincopy

2. public class Readwritemap<k,v> {

4. Private final map<k,v> Map;

6. Private final Readwritelock lock = new Reentrantreadwritelock ();

8. Private final Lock R = Lock.readlock ();

10. Private final Lock w = Lock.writelock ();

12. Public Readwritemap (map<k,v> Map) {

14. This.map = map;

16. }

18. Public V put (K key, V value) {

20. W.lock ();

22. try {

24. Return Map.put (key, value);

26. } finally {

28. W.unlock ();

30. }

32. }

34. Do the same for remove (), Putall (), Clear ()

36. Public V get (Object key) {

38. R.lock ();

40. try {

42. return Map.get (key);

44. } finally {

46. R.unlock ();

48. }

50. }

52. Do the same for other read-only Map methods

54. }

Toggle Context

When the thread is more, the operating system switching thread context performance consumption is not negligible, in building high-performance Web------Web server long connection can see the cost of process switching, of course, threads will be lighter, but the reason is similar

Memory synchronization

When used to synchronized, volatile, or lock, it is not possible to enjoy the performance optimizations of the JMM structure in order to ensure that the visibility results in more memory synchronization.

Java Multithreading Performance optimization