A few days ago, I helped a junior partner in another project team to solve a code problem. In fact, the problem was very simple, but the partner just worked for a short time, so some details might not be considered.

The main function of their code is as follows (pseudo code only) :

Receiving parameters;

Read the local key file;

Encrypt the received parameters;

Query the request URL from the database;

Send encrypted packets.

Copy the code

There is no problem in the process, but in fact there are two steps are repeated operations, one is to read the local key file, the second is to query the request URL from the database;

Do this every time you send a request. You can simply put the key file and URL in a static variable, initialize it once, and use it every time you send a message.

Let’s look at the modified code:

Static variables:



  byte[] Store the read key file and URL;



Separate methods:

ifbyteIf [] is null, initialize; If not empty, return;

If the URL is empty, initialize; If not empty, return;



Receiving parameters;

Method to get static variablesbyte[];

Encrypt the received parameters;

Obtain static variable URL through method;

Send encrypted packets.

Copy the code

Cache data load time

Let’s compare the code before and after (the code after is not without its drawbacks) :

  • Load each use: in the process of use, real-time access to the database configuration, the advantage is that when the configuration of the database has been modified, you can get real-time; Disadvantages are also obvious, that is, every time we have to do an operation, affecting efficiency;
  • Loading at project startup: If the initialization is done at project startup, the advantage is that the operation is only done once, but it should be considered whether there is a probability of exceptions during the initialization process; Once an exception occurs, these configurations are not loaded into memory, which is also dangerous;
  • First use load: The third is the one we use, which is initialized on first use; Compared with the first two methods, it is more efficient and safer. The disadvantage is that the configuration information changes, and the latest configuration will not be loaded unless the service is restarted. For this, you need to write extra code, such as loading the cache into memory, setting a timeout (periodically refreshing the cache); Or leave interface or page function, refresh cache actively; Of course, this extra development adds complexity to the code.

Location for storing cached data

In addition, it is not a particularly good idea to cache configuration information directly in a static variable, there are better practices:

  • Set up a static HashMap to store all cached data. In order to prevent the number of caches from being too large, strategies such as LRU can be used to eliminate caches.
  • Use a caching framework, such as Ehcache, to help with caching and flushing.
  • If the configuration information changes quickly and requires high real-time performance, you can consider storing it in a third-party cache system, such as Redis, and update the cache information through effective means. Of course, each call to Redis takes a certain amount of time, however short;
  • If the project has the development capability, it can set up a unified configuration center.

Of course, given that the project was very old and unlikely to add complex architectures, the “not particularly good way” was to load configuration information into static variables.

Uncle will point code | article “original”


The guy who knows how to code