These two days in reading <java concurrent programming combat, long time no writing, ready to start weeding. ^_^
The origin of concurrent programming:There was no operating system in the early days of the computer, only one program was supported for a certain period of time, and the program was able to access all the resources of the computer. After the program is fully executed, the next program is executed.
Benefits of introducing concurrent programming:
- Efficiency: The various parts of the computer are not busy, such as a program when using IO, the CPU can be used for another program. This increases the usage of the device.
- Fairness: Programs running on the computer should be treated equally, not one after the first execution, and then another program to start executing.
- Convenience: When calculating multiple tasks, it is easier to write multiple programs and, if necessary, communicate with each other, rather than having a program implement multiple tasks.
The earliest manifestation of concurrent programming is multi-process concurrent programming, which is introduced by the advent of the operating system. The benefits of this also contribute to the emergence of threads, which allow multiple programmatic flows in a process. With the implementation of Moore's law gradually shifted from the performance of single CPU to increase the number of CPUs, how to improve the resource utilization of multi-CPU becomes very important. These reasons make concurrent programming of threads more important.
Advantages of multithreaded programming:
- Unleash the power of multiprocessor: single-threaded routines run on a single CPU at some point, while multi-threaded routines can run on multiple CPUs, where efficiency gains are beyond doubt. What if there's only one CPU? There is only one CPU, in some scenarios, the multi-threaded procedure is still better than a single-threaded one, for example, a thread of the process is waiting for the release of the IO device, and the other thread of the process can use other devices, if there is only one thread, then we have to wait. - -
- Simplicity of modeling: By using threads, complex and asynchronous workflows can be further decomposed into a set of simple and synchronized workflows, with each workflow running in a separate thread and interacting at a specific synchronization location. This article actually affects the use of multithreaded technology, that is, often logically separate tasks with multithreading technology to achieve.
the risks that the thread poses:
- Security issues: In most cases, the threads are not completely independent, but work together to complete a task, so you may need to access a resource together, when multiple threads access and modify a variable at the same time, it is prone to such problems, this is the serial programming model introduced non-serial factors, This kind of problem is called the thread racing state.
- Active issues: Sometimes it is often necessary to control the order in which multiple threads are executed, such as one thread reading IO and the other thread taking from the previous thread, so we need to control the threads synchronously. Collaboration between threads can lead to problems such as deadlock, starvation, and so on. The thread will become inactive.
- Performance issues: Frequent thread switching, synchronization mechanisms (often suppressing compiler optimizations to invalidate data in memory buffers). Here is a question: the thread can perform some compound operations, in the use of the way and the process is not very different, why we are not on the basis of a further subdivision of the thread, such as to make a more granular scheduling unit "small thread", so that the execution of the program is not more efficient? A: This will further increase the number of program control flow, will lead to more frequent thread switching, in fact, the layer is divided into the thread is probably the best compromise. ^-^
Ubiquitous Threads:In the program we write ourselves, we usually pay attention to the thread-safe places:
- Timer: We write our own timed tasks, and the timer manages the threads that are called. Other threads are also very likely, so be aware of thread safety in this.
- Servlets and JSPs: Usually our servlets and JSPs are called by multiple threads at the same time, and the Web server assigns a thread to each incoming HTTP request from the thread pool. So we need to ensure thread safety in servlets and JSPs, and similarly, the servlet filters and objects that are stored in containers such as ServletContext and httpsession must be thread-safe.
- Remote Method Invocation (RMI): In RMI, there is the possibility of being re-entered by multiple threads, so you must ensure that their own thread security
Java Thread (i): Introduction to Concurrency
