preface

Thread-related interview questions have a long history, especially in the JAVA world

An architect once told me that those who do not understand threads are elementary, those who understand threads are advanced, and those who do not understand threads are intermediate.

You can see how threads play a role in interviews. However, the interview builds the rocket, the entry screw is the norm. Do we really need to learn threads?

Yes, it’s necessary!

Don’t you feel comfortable getting paid more than others to screw even if you do?

thread

What is a thread?

You are a thread

Or, you turn the screws like a thread.

A thread is the smallest unit of CPU scheduling in a computer.

So how does the computer allocate memory to the program, and it’s up to the operating system to manage the allocation, how does the operating system allocate memory uniformly?

This is where the concept of process comes in.

The operating system assigns each program a piece of territory and adds a label to record which program’s territory it belongs to.

We got to get to work when we’re done. Who’s going to do it? Threads are out, one thread per process is working.

And a process can have N threads.

However, only one thread of work can be executed at a time (on a single-core CPU).

This is called the minimum dispatch unit, or the minimum work unit.

So you’re a thread when you turn a screw. And there are tens of thousands of them in the company.

Thread safety

Let’s say you get a request for 200 screws, and you look at the document and there are 200 screws left. At this time your colleague also received this demand, a look at the document left 200 unscrewed. At this time you all went to screw one, each record -1, there are 199 unscrewed. But you’ve already screwed two of them, and that’s a problem.

Let me show you in code what happens when 300 people turn 200 screws.

package Thread; public class MyRun implements Runnable { public static int luosi = 200; @Override public void run() { for (int i = 1; i<=100; If (luosi > 0) {try {thread.sleep (50); } catch (InterruptedException e) {e.printstackTrace (); } luosi-= 1; System.out.println(thread.currentThread ()+" +luosi+"); }}}}Copy the code

Another entry function to execute:

package Thread; public class ThreadTest { public static void main(String[] args) throws InterruptedException { MyRun mr = new MyRun(); Thread mh = new Thread(mr); Thread mh2 = new Thread(Mr); // mh3 = new Thread(Mr); Mh.start (); mh2.start(); mh3.start(); }}Copy the code

Results:

Thread/Thread - 1, 5, the main twist the screw, and then there were: 2 didn't screw Thread/Thread - 0, 5, the main twist screws, left: 2 didn't screw Thread/Thread - 1, 5, the main twist screws, left: zero twist Thread[thread-2,5,main] unscrewed Thread[thread-0,5,main] unscrewed Thread[thread-2,5,main] unscrewed ThreadCopy the code

And let’s see how many screws we have

You can see 222 screws turned.

This is the legendary thread safety issue.

Data disorder occurs when multiple threads operate on the same data

Why did it go wrong

Think back to checking how many screws are left unscrewed before you turn a screw.

Because everyone has a copy of the document, they update their own copy first and don’t synchronize it with others in time.

This example and JAVA working mode is very similar, draw a picture to let you understand:

Each thread is working on its own workspace first, and the main memory update may not be timely.

How to solve

The classic one

  • lock

Ensure that only one person is operating at the same time, and directly update the main memory data, the party that gets the lock must also read the latest data from the main memory to operate.

JAVA solution:

  • synchronized
package Thread; public class MyRun implements Runnable { public static int luosi = 200; @Override public void run() { for (int i = 1; i<=100; Synchronized (myrun.class) {if (luosi > 0) {try {thread.sleep (50); } catch (InterruptedException e) {e.printstackTrace (); } luosi-= 1; System.out.println(thread.currentThread ()+" +luosi+"); } } } } }Copy the code

Results:

If Thread[thread-0,5,main] is unscrewed, there are 2 unscrewed threads. If Thread[thread-0,5,main] is unscrewed, there are 3 unscrewed threads Thread[thread-1,5,main] unscrewed Thread[thread-1,5,main] unscrewed ThreadCopy the code

How many twists:

This time it worked, and we solved the thread safety problem perfectly.

conclusion

Thread-safety problems can only occur when multiple threads are working on the same data, otherwise there would be no thread-safety problems. And the general way to solve this problem is to lock. In MySQL, multiple transactions operating on the same data are also isolated by locking. This creates a common problem, performance degradation, and even deadlocks.

Is locking the optimal solution to the thread safety problem?

And is it really necessary to enable multithreading when we are doing business requirements? I think these 200 screws can be turned faster by myself!

PS: Your praise is the motivation of my creation!