Java concurrent programming practice Chapter 1

1. The reason for promoting processes and threads is to solve the following problems:

• Resource Utilization
• Fairness
• Convenience

2. process: the operating system allocates various resources for each independent process, including memory, file handle, and security certificate. Processes can exchange data through coarse-grained communication mechanisms, including sockets, signal processors, shared inner storage, semaphores, and files.

3. Thread: the thread allows multiple program control flows in the same process at the same time. The thread will share resources within the process range, such as memory handles and file handles, but each thread has its own program counters, stacks, and local variables. A thread is also called a lightweight process. In most modern operating systems, it is a thread-based scheduling unit.

 

4. Thread advantages

• Multi-processor capabilities can be leveraged: multi-threaded programs can improve the system throughput by improving the CPU resource utilization.
• Simplicity of modeling: for example, in Servlet writing, you do not need to know how many requests are to be processed at the same time, and whether the input/output stream of the socket is blocked.
• Simplified processing of asynchronous events: for example, you can use multithreading to convert complicated non-blocking I/O into synchronous I/O, that is, each request has its own processing thread.
• Responsive user interface: An event distribution thread is used in tools such as AWT and Swing to replace the main event loop.

5. risks caused by threads

• Security issues: such as race conditions.
• Active problems: such as deadlocks, hunger, and live locks.
• Performance problem: Thread Scheduling is a very costly operation. When multiple threads share data, the synchronization mechanism must be used, which will usually suppress the optimization of Some compilers.

6. Solve the three methods of errors caused by multiple threads accessing a variable state variable

• This status variable is not shared between threads.
• Change the status variable to an unchangeable variable.
• Use synchronization when accessing status variables

7. Thread Security

When multiple threads access a class, no matter what scheduling method is used in the running environment or how these threads will be executed alternately, and no additional synchronization or collaboration is required in the main code, this class can show correct behavior, so it is called thread security. The correctness means that the behavior of a class is completely consistent with its specification. In good standards, various immutability conditions are usually defined to constrain the object state, and various posterior conditions are defined to describe the object operation results.

8. competitive conditions

When the correctness of a calculation depends on the time sequence of multiple threads, a race condition occurs.

"Check first and then execute" is a common race condition. In essence, it is based on a potentially invalid observation result to make judgments or execute a certain computing. The following code LazyInitRace contains a race condition, which may damage the correctness of this class.

public class LazyInitRace {     private ExpensiveObject instance = null;     public ExpensiveObject getInstance() {         if (instance == null) {              instance = new ExpensiveObject();         }            return instance;      }          }    

9. built-in locks

Java provides a built-in locking mechanism to support atomicity: Synchronous Code blocks. It consists of two parts: a Lock Object reference and a code block protected by the lock. Each Java object can be used as a synchronization lock. These locks are called built-in locks or monitoring locks. The thread automatically acquires the lock before it enters the synchronization code block and releases the lock when it exits the synchronization code block, whether it exits through the normal control path or throws an exception from the code block. The only way to obtain the built-in lock is to enter the synchronous code block or method protected by the lock.

• Java built-in locks are mutex locks: this means that only one thread can hold such locks at most.
• Java built-in locks can be reentrant: that is, if a thread attempts to obtain a lock held by itself, the request will succeed.