One of the concurrent programming

Source of concurrency

The origin of concurrency, from now on, seems to be inevitable. Because man is a lazy and impatient animal, it is human nature. Because of impatience, the concurrency arose, because the lazy, multicore era came.

Why do you say that?

If all the programs are serial (that is, if it is already concurrent when the LZ touches the computer, so you can only imagine), then when you open a particularly slow page, and finally you can't wait to close the browser, you'll find that you have to wait until you've loaded the page to get it done. This is one of the things that the egg hurts. Can impatient people allow this to happen? As a result, concurrency arises.

Imagine, if we want to make a program run faster, intuitively, we should make the CPU work faster. For example, once a second can be calculated 1000 times, now we let it in a second can be calculated 10,000 times. But lazy people find that this intuitive approach seems very difficult, and it is very difficult to abruptly the speed of the CPU (shortening the clock cycle). So lazy people think of a lazy way, a CPU can be calculated 1000 times a second, two words can not be calculated 2000 times (it is not the case, but we can understand the efficiency of multiple CPUs increased), this relatively simple approach was eventually adopted by people. So the multicore era is coming.

　　

Risk of concurrency

Speaking of the dangers caused by concurrency, in the LZ's understanding, mainly from the procedure to bring the intuition caused by misleading. This is described in the LZ's computer system principle (can link the contents of the two books), such as the following program, it gives the intuition that a first becomes 1, then B becomes 2.

    int a = 1;    int b = 2;

Intuition is like this, but often wrong, because when the program is actually executed, it may be that B first becomes 2,a and becomes 1, more wonderful is, it is likely that A and B are always 0. Estimated that the order of the two are reversed, you can understand, but when it comes to both may be 0, some ape friends are ignorant, there is a moment to subvert the three views of the feeling, but learning concurrency is often the process of subverting your three views.

This difference between intuition and reality poses a risk to concurrent programs. It can cause errors that you anticipate, and are often impossible to guard against. So concurrency is tempting, but it's also dangerous, and a tempting thing is always dangerous, like a noble rose that's always a thorn.

Knowing the above, we can look at security and activity. Security refers to "the program does not show bad things", the activity is that "good things will happen". As can be seen, security is more emphasis on the implementation of the program is correct, and the more active is stressed that the program can be carried out correctly (a bit around?). That's right).

For example, for a program that has a concurrent recursive solution, security guarantees the correctness of the results, while the activity ensures that the program always gets a correct result or finds that it has no solution and throws an exception without a solution.

　　

Concurrency in Java

For most of the Java development in the near future of the program ape (including LZ), concurrency is generally rarely accessible (mainly in the LZ field, that is, the Java EE), because the existing framework has a lot of concurrency problems to solve, and give us these non-brain program Ape created a serial program environment.

For example, in the servlet specification of the Java EE domain, the servlet is singleton, and it is very possible, and can even be said to be accessed by multiple threads concurrently. So the servlet has a concurrency security problem, unless you don't record any state in the servlet. But the current comparison of the fire of the MVC framework Struts2 has helped us solve this problem, although the action often has some data or state, but the action in the Struts2 is a singleton, which is equivalent to each action instance is thread-private, so there is no concurrency problem.

In some cases, we may be exposed to concurrency problems, for example, you need to do a singleton object, then this object can generally be accessed globally, so there may be concurrency problems. It can be said that almost all objects that take a singleton pattern involve concurrency problems, unless the object has no state, but this tends not to occur, because stateless singleton objects are meaningless, and their better handling should be a class that has no instances (the constructor is privatized) and is full of static methods.

Many program apes, when they first realize concurrency, take a seemingly omnipotent but not necessarily useful approach, which is to add all the methods of a class to the Synchronized keyword. LZ used to be such, but also think very high-end, now think, LZ really ashamed. At that time the LZ's understanding of the synchronized that it would allow many threads to execute this method on one, and that the other features were not quite clear.

In fact, most of the time, some of the more simple scenes, the above such a no-brain approach can play a corresponding role, that is, it can guarantee security and activity. But another feature is not guaranteed, that is performance. A brain-free approach to synchronization, sometimes reducing performance by several orders of magnitude, may cause many threads to wait, while the CPU is still at 1% utilization.

Typically, for security, activity, and performance, we'll put performance on the last one, referring to a classic phrase we've seen before, which is used to describe object-oriented design, "reusable premise is available." Similarly, for concurrent programs, the "High performance premise is that the execution of the program is correct".

Summary

Today for the moment to write so much, for concurrency, actually want to say that there are many, after all, just finished reading this book. There will be a succession of their own understanding, but will be interspersed with the "Computer system principle Series" content, this series should continue to move forward, because the concurrency has delayed it too long.

Original link: http://www.cnblogs.com/zuoxiaolong/p/life24.html

One of the concurrent programming