Java Virtual machine and concurrent processing several problems briefly (i)

One, when processing a task, the code should be divided into different parts, each of which is performed by one thread, but is busy because of unbalanced task load. It is best to divide into different parts, assign different threads, try to keep the processor up and running, not idle. How to assign the number of threads, there is a formula:

Number of threads = number of processor cores/(1-blocking factor) the blocking factor is between 0~1.

Second, two cases of processing concurrency: 1, io-intensive. 2, deal with prime problems. Two examples represent two cases.

Third, what is JIT?

In the Java programming language and environment, the instant compiler. When JIT compilation is enabled (enabled by default), the JVM reads the. class file after it is interpreted and sends it to the JIT compiler. The JIT compiler compiles the bytecode into the machine code of the cost machine. Usually Javac compiles the program source code into Java bytecode, and the JVM translates it into the corresponding machine instruction by interpreting the bytecode, reading it each time, explaining the translation by clause. Obviously, after interpretation, the execution speed must be slower than the executable binary bytecode program. In order to improve execution speed, JIT technology was introduced. At run time JIT will save the translated machine code, ready for the next use, so in theory, the use of this JIT technology can be close to the previous pure compilation technology.

Client compiler: At run time, compile the bytecode you write into assembly code. This means that he will slow down the start-up time of your application, as well as a lot of optimizations to start after the program has been running for some time. And the biggest drawback is that the resulting code cache occupies memory, because the client compiler consumes memory and causes the cache of the optimized assembly code to not be stored.

Server-side compiler: He did not compile from the start, but to let the program run for a period of time before starting the assembly, this process can be called the program's warm-up process. The bytecode is then compiled into a sink encoding, and the cache of the assembly is stored.

Four, several important variable modifiers can ensure that synchronization or the processing of several threads for an instance of an object can be shared. For example, the role of the keyword volatile is to tell the JIT compiler not to perform any optimizations that might affect the order in which it accesses the tagged variable. The keyword warns the JIT compiler that a variable may be changed by a thread, so any read-write access to the variable needs to ignore the local cache and manipulate the memory directly.

V. Definition of memory fence:

In a nutshell, memory Barrier is the copy action from the local or working memory to the main storage.

Changes made by a write thread are visible to other threads only if the write thread crosses the memory fence first and the read thread crosses the memory fence. The keyword synchronized and volatile both enforce that all changes must be globally visible, which facilitates the occurrence of actions across memory boundaries, whether intentional or unintentional.

When the program is running, all changes are made to the register or the local cache before being copied to main memory to span the ram fence. This type of spanning sequence or sequence is called Happens-before, and the write operation must be Happens-before read, that is, the write thread needs to complete its own spanning action before all the read threads cross the memory fence, making changes that can be made visible to other threads.

Many operations in the Java Concurrency API imply the implication of crossing the memory fence: The functions in volatile, synchronized, thread, such as Start () and interrupt (), Functions in Executorservice and synchronization tool classes such as Countdownlatch.

Java Virtual machine and concurrent processing several problems briefly (i)