"I can do it locally, why can't I do it in production???"
I believe everyone has said the above sentence, and now it seems to be jokingly called "the biggest lie of programmers", hehe... I will summarize the lessons based on my personal experience.
Scenario 1: Compile the classes that are compiled locally and tested correctly into class files and put them in the production environment.
In most cases, we do this. The code that runs well locally can't run in production, and it still doesn't report an error...
When I encountered this situation, it was because I commented in the local java file corresponding to the class file, method A, which did not need to be online for the time being, and method A called method B. The code in method B involved To other classes or methods that have not been submitted online. Although the local compilation is correct, a class file is also generated, and I also commented out the caller method A of the new function, but it is actually a compilation error to directly put this class file into the production environment. Because the class file of the production environment does not yet have the uncommitted class or method in your method B...
The method is to submit your code and update it by the team leader responsible for the upgrade and packaging. His corresponding Java file must not be compiled because method B fails to compile. Because you can't submit B for the time being, so he deletes your newly added (not yet online) function method A and its dependent method B, and then repackages it into a class file.
The above requires the normative operation of our upgrade package. . This potential mistake is easy to make.
Scenario 2: Make sure that the jdk version environment of the local environment and the production environment is the same, because different jdk versions have slightly different support for some syntaxes.
Scenario 3: The local environment is generally a stand-alone environment. In most cases, the production environment is load-balanced. When some cached data needs to be stored in the memory at startup, restarting the machine will clear the cached data in the memory . If you need to read the cached data, when the initialization has not been completed, it may often cause a NullPointerException (because it takes a certain time to initialize into the cache.). If you want not to be affected by restart, it is recommended to store cached data in nosql database, such as redis, mongodb, cassandra, etc., so that multiple machines share the same cache middleware, and restarting any machine will not cause the cached data to be emptied. When reading the cached data, it is changed to read from the cache middleware instead of the memory. When the project is started, it is best to use the asynchronous method to initialize the cache, rather than the thread blocking method. .
Scenario 4: Rerun for the same batch of data, expecting the data to cover the original data, but it turns out that it is duplicated. - Check whether the primary key of the table is generated by the automatic generation strategy.
===================== Continue to add ===========================