Java program multithreading test notes

First of all, it should be clear that it is "very" difficult to build a multi-thread security program using Java. If you have not realized "very, read "Java Concurrency in Practice" (the Chinese name is "Java concurrent programming Practice". in my book list, I think it is basically the best book to introduce Java Concurrency) this may change your opinion.

Multithreading basics

The foundation is Wang Dao. This is true for any language. Some basic components are irrelevant to the language, and some are related to the Java language. I will not expand it here, but I would like to mention my understanding of the JSR specification. We usually think that Java is ?? Long (4) long enough? What are zookeeper ?? Why is it because of the well-known ping file ?? ?? Why ?? ? Ava multi-threaded program, but not at all, need to know a lot of things, such as JSR-133 and JSR-166 these two most important specifications.

Good design

This must be placed in the first article. Software quality is not tested, but designed. Simplify the problem as much as possible and take the initiative to avoid some potential problems. For example, I have discussed in this article why the multi-threaded GUI framework is hard to be designed; for another example, the NeedsRefreshException criticized in OSCache, the design mechanism determines that it has many bugs and is prone to deadlocks. Some widely recognized experiences are the reference for guiding software design. Naturally, from the design stage, the program's interpretation of logic multi-thread execution is kept clear and simple, so that the code can be reliable.

Code review

For some potential problems that are difficult to construct test cases to cover, the code review is almost the last dam that may systematically discover the problem. Of course, the limitations of code review are obvious, and the review users are easy to fall into details. In the general sense, coding habits and normative issues, or the potential problems of multithreading caused by the use of a single class are easy to find, but the problems of resource usage and conditional Association in the case of concurrent classes and components are difficult to find out.

Auxiliary tool check

For a tool such as FindBugs, you can take a look at the "Multithreaded correctness" section in the bug description list. Of course, likewise, there are tools such as PMD. Both of these tools can be used to identify errors for compiled classes, rather than just source code files. Another tool named Coverity Code Advisor, which I also heard for the first time. However, the company Coverity, Wang Yin once wrote an article and commented on it. If you are interested, you can go to his blog to find it.

Now it's time to really talk about the part of the test. However, even so, I still want to say that many problems of multi-threaded programs are hard to be found through testing. Relying on testing to ensure quality can only be said as the next strategy here.

Stress testing

First, it should be clear that, like testing in all cases, testing problems can only be used as adequate conditions and cannot be used as necessary conditions, that is to say, the problem found in the multi-threaded program test only indicates that this multi-threaded program has a problem, but the program may not be able to be found through the test if there is a problem. The easiest way to think about it is to execute the multi-threaded code logic repeatedly in a multi-threaded scenario, especially for controllable stress testing, so as to expect unexpected results from several running operations. This is the most crude and simplest way. This method is irreplaceable. However, the appearance of many multi-threaded problems is complicated, and this method is obviously unpurposeful, with the feeling of shooting birds with bullets.

Debug algorithm

Funny, right? Do not underestimate the single-step execution. Especially for the combination of execution branch paths in different threads, you can use the single-step debugging method to simulate many situations. Of course, such a test must be a white box. I do not believe that a black box tester who does not view the tested code can do this well.

Framework for multi-threaded program testing

This depends on the specific situation. Amazon has such a set of internal-use concurrency testing frameworks. In my previous company, I have seen someone in other departments write this framework, which is basically the same as writing traditional test code, by using annotations or a few simple tool-class controls, you can flexibly specify parallel test parameters, such as the number of threads (with code specified or command line parameters specified ).

Some interesting open-source libraries

For example, Thread Weaver is used to write multi-Thread unit tests. The principle of this library is to create some breakpoints in the code, and then the breakpoint can be mounted when the code is executed, in this way, you can test the combination of resource contention and conditions. For a simple example, first define an object like MyList:

Public class MyWriter {
Private StringBuilder sb = new StringBuilder ();
Private int counter = 0;
 
Public synchronized void write (String s ){
Sb. append (++ counter + "-" + s + "");
    }
    
Public synchronized String toString (){
Return sb. toString ();
    }
}

Test it now:

Public class MyWriterTest {
Private MyWriter writer;
 
@ Test
Public void testThreading (){
AnnotatedTestRunner runner = new AnnotatedTestRunner ();
// Run all Weaver tests in this class, using MyList as the Class Under Test.
Runner. runTests (this. getClass (), MyWriter. class );
    }
 
@ ThreadedBefore
Public void before (){
Writer = new MyWriter ();
    }
 
@ ThreadedMain
Public void mainThread (){
Writer. write ("MainA ");
Writer. write ("MainB ");
    }
 
@ ThreadedSecondary
Public void secondThread (){
Writer. write ("SecondA ");
Writer. write ("SecondB ");
    }
 
@ ThreadedAfter
Public void after (){
System. out. print (writer. toString ());
    }
}

Here, @ ThreadedBefore and @ ThreadedAfter are a pair. For example, in the API documentation, the author explains: "An annotation that designates part of a test suite that uses the AnnotatedTestRunner framework to perform multithreaded tests. A method tagged with the ThreadedBefore attribute will be run before every test case. ", I initially thought that all the annotations starting with Threaded would start two threads for parallel execution by default. Later I found that they were actually executed twice, however, by printing the thread number in the @ ThreadedBefore/After code, we found that the thread numbers for both times are the same, and I am not very clear about the mechanism here;

During each execution of the preceding steps, the @ ThreadedMain and @ ThreadedSecondary annotation modifiers are placed in separate threads for parallel execution.

One of the possible output results is as follows:

1-MainA 2-SecondA 3-MainB 4-SecondB 1-MainA 2-SecondA 3-MainB 4-SecondB

Of course, it may also be:

1-MainA 2-SecondA 3-SecondB 4-MainB 1-MainA 2-SecondA 3-MainB 4-SecondB

And so on.

Thread Weaver also allows the use of CodePosition for fine-grained control, which is a little complicated. Examples in this document indicate that the debug process is code-oriented.

For another example, JPF is called Java Pathfinder, which is a customizable Java Bytecode eXecution Environment and is often used for Java program debugging and verification. With it, you can find some errors of Java programmers, collect runtime information, infer test vectors and create corresponding test drives. It detects all possible execution paths of programs on the system to detect deadlocks or unhandled exceptions.