Case number one:
Because the initialization of the member variables is written in the construction method, so that the original model calculation has to be initialized once, it becomes the object that is created once and only once, and only once for a batch of calculations.
Phenomenon: The result of single calculation and debugging on the local test class of WINDOWS is correct, but the same code is put on LINUX and the result of batch calculation is wrong.
At the beginning, I found that the results of batch calculation on Linux were very outrageous. The first thing we thought of was that the package was mistyped. Our code is divided into two parts, one is that JAVA takes the input parameters of the model from the database, and then JAVA calls C++ to perform model calculations, and the calculation results are returned to JAVA and then entered into the database. We checked whether the packet size of Linux was the same as the packet size on the test environment, and found that they were the same. Then we speculated whether only part of the program was modified, resulting in no significant change in the package size. We re-typed the C++ and JAVA packages and found that the phenomenon was still the same. Local single-step debugging is not the same as the result of running on Linux. At that time, our test class only supported single model calculations and not batch calculations. We didn't think it was a code issue at all, but we thought about environmental issues and configuration issues. Because after code comparison, my local code and the packaged code are exactly the same. If the result of a single calculation model on my local is correct, I think the code is correct. On Linux, you cannot set a single-step breakpoint like a local one, so you have to keep adding logs and checking logs. However, the same log file is written by multiple processes in batch calculation at the same time, which causes the logs to be mixed. Then turn off the redundant processes and leave only one process, so that the logs will not be mixed up. However, the amount of calculation is large, and only one process is left. Every whole process calculation takes a lot of time, but the result is not the same as the local one. Is it absolutely not desperate? The log file is very large, and the primary key ID of the input parameter is not passed to C++, which makes it difficult to locate the model parameters I tested locally in the log file. I firmly believe that my code is okay, otherwise the results I ran locally would not be correct. When investigating this problem, from the morning to the early morning of the next day, people were stupid, thinking about whether every step might go wrong, and constantly experimenting, and tried everything. Finally, the team leader who accompanied the overtime work suggested that the local test class should be changed to be consistent with the process on Linux, and it should be changed to support batch calculation. I still think it’s an environmental problem, not a code problem. Changing the test class is a waste of time. The time is too late. The desire to change the code is very low, but it took some time to change the code and lost it hopelessly. Run and see a few parameters. Damn, the mistake was reproduced unexpectedly. It took less than two minutes to locate the problem and change it.
Code reason, each calculation task runs a batch of model input parameters, but each task only creates the same type of model input parameter object once. I wrote the default value initialization of the input parameters in the construction method, and each calculation requires initialization. The result of initializing the model parameters in the construction method is that a batch of model parameters are initialized only once, so there is no problem in running a single model parameter.
Case 2:
A new "scene" field has been added to the combined primary key of model parameters, and the key used for caching with HashMap in the code has not been changed, resulting in different model input parameters under different "scenes", but the calculation results of different "scenes" are exactly the same.
Phenomenon: The input parameters of the model under different "scenes" are different, but the calculation results of different "scenes" are exactly the same.
I immediately decided to reproduce the problem. I tested a model input and found that it was different from the result of running on Linux. First, change the test class to support multiple "scenarios". Then prepare and test the conditions locally on Linux. This is a tedious process...Finally, because the test conditions are not exactly the same, the results of the calculations run locally and on Linux are not the same, but this is not a problem, because the bug phenomenon is successful Reproduced, all the parameters taken under different "scenes" are different, but the results are all the same.
Finally, it was found that the Key value in the cache did not add the "scene" field, and the Key was still the original id primary key, resulting in the associated parameters being the first associated parameters of the same id model parameter. So the calculated result is the result of the first model parameter with the same id.