"Java Concurrent Programming Practical" Reading Notes 9--concurrent program test

The 12th chapter of concurrent Program testing

Broadly divided into two categories: security testing and active testing

12.1 Correctness Test

Identify the invariance conditions and posterior conditions that need to be examined. Next, you will build a set of test cases to test a bounded cache. Listing 12-1 shows the implementation of Boundedbuffer, which uses semaphore to implement the bounded properties and blocking behavior of the cache.

The Boundedbuffer implements a fixed-length queue that defines a blocking put and take method and controls it with two count semaphores. (In real life, if you need a bounded cache, you should use Arrayblockingqueue or linkedblockingdeque instead of writing it yourself).

12.1.1 Basic Unit Testing

The most basic unit tests for Boundedbuffer are similar to tests performed in a serial context. First create a bounded cache, then call its various methods, and verify its post-condition and invariance conditions. We will soon think of some invariance conditions: the newly created cache should be empty, not full. Another slightly more complex security test is to insert n elements into a cache of capacity N, and then test whether the cache is filled.

12.1.2 testing for blocking operations

When testing the basic properties of concurrency, you need to introduce multiple threads. Most test frameworks do not support concurrency testing well. In Java.util.concurrent conformance testing, it is important to explicitly correlate the various failures with specific tests. As a result, the JSR 166 Expert group created a base class that defines some of the failure information that can be passed and reported during teardown, such as garbage collection after the completion of the test, and follows a convention: each test must wait until all the threads it creates are finished.

If a method needs to be blocked under certain conditions, when testing this behavior, the test is successful only if the thread is no longer executing. To test the blocking behavior of a method is similar to testing a method that throws an exception: If the method returns normally, it means that the test failed. When you test the blocking behavior of a method, additional complexity is introduced: When the method is successfully blocked, you must also use method contact blocking. An easy way to do this is to use interrupts--to start a blocking operation in a separate thread. Here's an example:

Look at the back forget the front ... Now fill in some of the previous knowledge:

(1) Interrupts are done by calling the Thread.Interrupt () method. This method informs that thread by modifying the interrupt state of the called thread, saying that it was interrupted. For non-blocking threads, only the interrupt state is changed, that is, thread.isinterrupted () will return true; For threads in the unblocking state that can be canceled, such as a thread waiting on these functions, Thread.Sleep (), object.wait (), Thread.Join (), this thread will throw interruptedexception after receiving the interrupt signal, It also resets the interrupt state back to false.

(2) The T.join () method blocks the thread that calls this method (calling thread) until the thread is finished, and the thread continues, usually for the main () main thread, waiting for other threads to finish before the main () main thread

If the take operation is stalled for some unexpected reason, then the join method that supports the time limit ensures that the test is finalized. The Thread.getstate method used to verify that a thread can block on a conditional wait is unreliable (see p208)

12.1.3 Security Testing

Several of the above test programs cannot find errors that are caused by data contention. An effective way to test the classes used in the producer-consumer pattern is to examine the individual elements that are placed in the queue and taken out of the queue. The checksum of all into row and dequeue elements can be computed and compared by a sequence-sensitive checksum calculation function. If the two are equal then the test dies successfully. If you want to extend this approach to multi-producer-multi-consumer mode, you need a checksum function that is insensitive to element into row/dequeue order, so that after the test program runs, multiple checksums can be combined in different order. (This part looks at all kinds of Meng)

When the thread reaches the fence position, it calls the fence's await method, which blocks until all the threads have reached the fence position. If all the threads have reached the fence position, then the fence will be opened, all threads will be freed, and the fence is reset for the next use.

12.1.4 Resource Management test (P212)

12.1.5 using callbacks (p213)

12.1.6 to generate more alternating operations (p214)

Because most of the errors in the concurrency code are low-probability times, you need to perform multiple iterations repeatedly when testing for concurrency errors, so you sometimes need to generate more alternating operations. A useful approach is to use Thread.yield to generate more context switches in operations that access shared state.

The yield method changes the current thread from the execution state (running state) to the executable (ready state). The CPU is chosen from a multitude of executable states, that is, the thread that is just now is still likely to be executed again, not necessarily executing another thread and the thread will not execute the next time.

It should be the cutting of the aspect-oriented programming, and again the quality of the translation of the book Under the Groove.

12.2 Performance Test (p215)

12.2.1 added chronograph function in Puttaketest (p215)

Record the time of the entire run, divided by the amount of the operand, to get the run time of each operation. Use a fence action to measure start and end times:

Honestly this Part I see Foggy, do not know is not the reason of translation (in the Frying pan ...), two week head prepare to take the English version of this book to see again.

12.2. Comparison of more than 2 different algorithms (p217)

12.2.3 Responsiveness Measurement (p219)

12.3 Pitfalls of avoiding performance tests (P220)

12.3.1 garbage Collection (p220)

The execution timing of garbage collection is unpredictable, so the garbage collector may run at any point when the test is executed.

12.3.2 Dynamic Compilation (P220)

12.3.3 false sampling of code path Strength (p222)

12.3.4 the level of non-true competition (p222)

Elimination of 12.3.5 useless Code (p223)

12.4 Other test methods (p224)

Summary: This chapter basically to the back to see not understand ..., said a lot of theoretical things. In fact, I always feel that the theory of this thing is useless, to be based on the practice of understanding. Instead of starting from the theory, we should compare the teaching methods of practicing theory. Here again the quality of the translation of this book, Pit AH.

"Java Concurrent Programming Practical" Reading Notes 9--concurrent program test