"Java" multithreading conflict resolution--synchronous lock

Reprint please specify the original address: http://www.cnblogs.com/ygj0930/p/5827547.html the most effective way to solve the parallel conflict is to add the synchronous lock, mainly have the following methods: 1: Dynamic method Synchronous Lock: Lock the current object. That is, the class object that invokes the method takes precedence over the next task. Public synchronized void Method () {} Instance code:

Import Java.lang.Thread.State;

Import Org.omg.CORBA.PUBLIC_MEMBER;

public class ThreadTest {
public static void Main (string[] args) throws exception{
Myrunnable m1=new myrunnable ();
Thread T1=new thread (m1);
Thread T2=new thread (m1);
T1.start ();
T2.start ();
T1.join ();
T2.join ();
System.out.println (Myrunnable.num);
}
}
Class Myrunnable implements Runnable
{
public static int num=0;
Public synchronized void Add ()
{
for (int i=0;i<100;++i)
{
num++;
}
}
@Override
public void Run () {
Add ();
}
}

Result: 2002: Static method Synchronous Lock: Locks the current class. That is, all class objects of the class take precedence. All objects of this class that have been invoked to run are peers and run alternately. These objects are preferred for objects of other classes and are executed first. public static synchronized void method () {} instance:

Import Java.lang.Thread.State;

Import Org.omg.CORBA.PUBLIC_MEMBER;

public class ThreadTest {
public static void Main (string[] args) throws exception{
Myrunnable m1=new myrunnable ();
Myrunnable m2=new myrunnable ();
Thread T1=new thread (m1);
Thread t2=new thread (m2);
T1.start ();
T2.start ();

T1.join ();
T2.join ();
System.out.println (Myrunnable.num);
}
}
Class Myrunnable implements Runnable
{
public static int num=0;
Public synchronized static void Add ()
{
for (int i=0;i<100;++i)
{
num++;
}
}
@Override
public void Run () {
Add ();
}
}

Results: 200

3: Code Sync Lock: Sets an object (hydrangea) that identifies who will execute the block of code being locked. Who gets this object (grab hydrangea), who will execute. And, in the course of the implementation of the hydrangea may be snatched, this is the time to snatch the hydrangea thread class to execute this code. Runnable () {
public Object Lock=new object ();   public void Method () {synchronized (lock) {code block}; }
If the two thread class objects use the same runnable parameter, then the lock object is common, and two threads who get the lock object who run the lock code block, the end result is OK.

Import Java.lang.Thread.State;

Import Org.omg.CORBA.PUBLIC_MEMBER;

public class ThreadTest {
public static void Main (string[] args) throws exception{
Myrunnable m1=new myrunnable ();

Thread T1=new thread (m1);
Thread T2=new thread (m1);
T1.start ();
T2.start ();

T1.join ();
T2.join ();
System.out.println (Myrunnable.num);
}
}
Class Myrunnable implements Runnable
{
public static int num=0;
public Object Lock=new object ();
public void Add ()
{
Synchronized (lock) {
for (int i=0;i<100000;++i)
{
num++;
}
}
}
@Override
public void Run () {
Add ();
}
}

Results: 200000

If the two thread class objects do not have the same runnable object parameter, then two threads correspond to one lock code block, and the two threads run the lock code block independently, but alternating CPU usage can cause erratic results.

Import Java.lang.Thread.State;

Import Org.omg.CORBA.PUBLIC_MEMBER;

public class ThreadTest {
public static void Main (string[] args) throws exception{
Myrunnable m1=new myrunnable ();
Myrunnable m2=new myrunnable ();
Thread T1=new thread (m1);
Thread t2=new thread (m2);
T1.start ();
T2.start ();

T1.join ();
T2.join ();
System.out.println (Myrunnable.num);
}
}
Class Myrunnable implements Runnable
{
public static int num=0;
public Object Lock=new object ();
public void Add ()
{
Synchronized (lock) {
for (int i=0;i<100000;++i)
{
num++;
}
}
}
@Override
public void Run () {
Add ();
}
}

Multiple debugs: The result is random, the larger the number of cycles the more random the result. For example, if the above for loop is i<100, then the result will always be 200, which looks right, yes. The reason is that the number of loops is too small and the two threads have little effect on the results. When the number is adjusted, such as 100000, the result is very random, it may be 103453,112378 ....

"Java" multithreading conflict resolution--synchronous lock