Thread safety issues

The landlord of this article mainly to the user in the ticket Office purchase tickets for the background of multi-threaded implementation. Suppose a city to B city tickets Total 50, a total of 3 ticket window in the ticket, using multi-threading to simulate the ideal situation of the user purchase tickets:

The ticket class for implementing runnable:

1 package com.jon.thread;  2  3 public class Ticketsell implements Runnable {4     private int tickets = 50;//Set ticket Number 5     @Override 6     Public void Run () {7         while (true) {8             if (tickets>0) {         9                 //output is currently which thread is selling the first few tickets of                 System.out.println ( Thread.CurrentThread (). GetName () + "on sale" + (tickets--) + "Ticket");             }12         }13     }14 15}

After the simple ticketing business was built, we tested it with three threads simulating the ticket window:

1 package com.jon.thread; 2  3 public class Ticketselltest {4 public     static void Main (string[] args) {5         Ticketsell ts = new Ticketsell ( ); 6         Thread TD1 = new Thread (TS, "ticket window 1");//Set thread name to differentiate which ticket window 7         Thread td2 = new Thread (TS, "ticket window 2"); 8         Thread TD3 = new Thread (TS, "ticket window 3"); 9         Td1.start ();         Td2.start ();         Td3.start ();     }13}

As you can see from the output, three threads are preempted to fully sell 50 tickets:

View Code

But in a real-world scenario, we usually take into account the delay in buying tickets due to other factors such as network latency, where we will ticket a little bit:

1 package com.jon.thread;  2  3 public class Ticketsell implements Runnable {4     private int tickets = 50;//Set ticket Number 5     @Override 6     Public void Run () {7         while (true) {8             try {9                 thread.sleep (100);//thread Sleep 100 milliseconds is used to simulate a delay of ten             } catch ( Interruptedexception e) {                 e.printstacktrace ();             }13             if (tickets>0) {+                 // The output is currently which thread is selling the first few tickets to                 System.out.println (Thread.CurrentThread (). GetName () + "being sold" + (tickets--) + "Ticket"); 16             }17         }18     }19 20}

Run again, you can see some ticket window sold the same ticket, even appeared 1, 0, it is obvious that there is a thread safety problem:

 1 Ticket window 1 is selling the 49th Ticket 2 ticket window 2 is selling 49th Ticket 3 ticket window 3 is selling 50th Ticket 4 ticket window 2 is selling 48th Ticket 5 ticket window 1 is selling 46th Ticket 6 ticket window 3 is selling 47th Tickets 7 Ticket window 2 is selling 45th tickets 8 Ticket window 1 is selling the 44th ticket//Window 1, 3 sold the same 44th Ticket 9 ticket window 3 is selling 44th ticket 10 ticket window 2 is selling 43rd Ticket 11 ticket window 1 is selling 41st Ticket 12 ticket window 3 is selling 42nd tickets 13 Ticket window 2 is selling the 40th Ticket 14 ticket window 3 is selling 39th Ticket 15 ticket window 1 is selling 39th ticket 16 ticket window 1 is selling 38th Ticket 17 ticket window 2 is selling 37th Ticket 18 ticket window 3 is selling 36th tickets 19 Ticket window 1 is selling the 35th Ticket 20 ticket window 3 is selling 33rd Ticket 21 ticket window 2 is selling 34th ticket 22 ticket window 1 is selling 32nd Ticket 23 ticket window 3 is selling 31st Ticket 24 ticket window 2 is selling 30th tickets 25 Ticket Window 3 is selling the 29th Ticket 26 Ticket window 1 is selling 29th Ticket 27 ticket window 2 is selling 28th ticket 28 ticket window 3 is selling 27th ticket 29 ticket window 1 is selling 27th ticket 30 ticket window 2 is selling 26th tickets 31 Ticket window 1 is selling the 25th Ticket 32 ticket window 3 is selling 24th Ticket 33 ticket window 2 is selling 23rd Ticket 34 ticket window 1 is selling 22nd Ticket 35 ticket window 3 is selling 21st Ticket 36 Ticket window 2 is selling 20th tickets 37 Ticket window 1 is selling the 19th Ticket 38 ticket window 3 is selling 18th Ticket 39 ticket window 2 is selling 17th Ticket 40 ticket window 3 is selling 16th Ticket 41 ticket window 1 is selling 15th Ticket 42 ticket window 2 is selling 14th tickets 43 Ticket Window 3 is selling the 13th Ticket 44 ticket window 1 is selling 12th Ticket 45 ticket window 2 is selling 11th Ticket 46 ticket window 1 is selling 10th Ticket 47 ticket window 3 is selling 9th Ticket 48 ticket window 2 is selling 8th Tickets 49 Ticket window 1 is selling 7th tickets 50 Ticket Window 3 is selling the 6th Ticket 51 Ticket window 2 is selling 5th Ticket 52 ticket window 1 is selling 4th Ticket 53 ticket window 2 is selling 2nd ticket 54 ticket window 3 is selling 3rd Ticket 55 ticket window 1 is selling No. 0 Tickets 56 Ticket window 3 is selling 1th tickets 57 Ticket window 2 is selling 1 tickets//Even appeared-No. 1th, No. 0

Reasons for this result:

Assuming that the system sells the "44th ticket", the Thread "ticket window 1" Gets the CPU execution right, which is represented by the process:

The question of determining whether an application is thread safe is the following:

* Whether it is a multithreaded environment * whether there is shared data * If there are multiple statements to manipulate shared data

It is obvious that the above procedures meet these three points, to solve the idea: multiple statements to manipulate the shared data code to lock up, so that at any time only one thread can execute. Landlord here using synchronous code block transformation ticket class as follows:

1 package com.jon.thread; 2  3 public class Ticketsell implements Runnable {4     private int tickets = 5     private Object obj = new Objec T (); 6     @Override 7 public     Void Run () {8 while         (true) {9             synchronized (obj) {Ten                 try {one                     thread.sleep ( (                 interruptedexception e) {                     e.printstacktrace (),                 }15                 if (tickets>0) {                -                     System.out.println (Thread.CurrentThread (). GetName () + "on sale" + (tickets--) + "Ticket"); +                 }18             }         }20     }21 22}

To run again, the results are as follows:

View Code

You can see that there are no more duplicate tickets appearing. Of course, synchronous code block also has its drawbacks, when the thread is quite a long time, because each thread will be to determine the synchronization of the lock, which is very resource-intensive, virtually reduce the efficiency of the program running.

Thread safety issues