Software System Stability

 

The stability of the software system is mainly determined by the overall system architecture design. However, the details of programming cannot be ignored. The so-called "treasure of a thousand miles, let the ant hole", once not considered weekly, seemingly insignificant code snippets may cause the overall software system to crash. This is exactly how I read Release It! . On the one hand, programmers are not pursuing the quality of Code. Under the pressure of project progress, they only consider the function implementation, rather than the excessive pursuit of quality attributes; second, I do not know enough about the correct encoding method of the programming language, and I do not know how to effectively and correctly encode the language. Third, I do not know how much knowledge is required, when programming, you are not aware of the factors that affect the implementation.

For example, in Release It! The following Java code snippets are provided in this book:

package com.example.cf.flightsearch; //... public class FlightSearch implements SessionBean {private MonitoredDataSource connectionPool;public List lookupByCity(. . .) throws SQLException, RemoteException { Connection conn = null; Statement stmt = null;try { conn = connectionPool.getConnection(); stmt = conn.createStatement();// Do the lookup logic// return a list of results} finally { if (stmt != null) {stmt.close();}if (conn != null) { conn.close();}}}}

This short piece of code is the culprit of the Airline system crash. The programmer fully considers the release of resources, but in this code, he does not pay enough attention to the release of multiple resources. Instead, he handles multiple resources by releasing a single resource. In the finally Statement block, if the operation to release the Statement resource fails, an exception may be thrown because the exception is not caught in finally, resulting in the subsequent conn. if the close () statement is not executed, the Connection resource cannot be released in time. Eventually, the Connection pool stores a large number of Connection resources that cannot be released in time, but cannot be used until the Connection pool is full. When lookupByCity () is requested subsequently, it is blocked when the connectionPool. getConnection () method is called. These blocked requests will increase and eventually lead to resource depletion and the entire system crashes.

Release It! The author also warned about the use of the synchronization method in Java. Although the synchronization method can better solve the concurrency problem, it can avoid resource preemption, final state conditions and deadlocks to a certain extent. However, a side effect of the lock may cause thread blocking. This requires that the execution time of the synchronization method should not be too long. In addition, the Java interface method cannot mark the synchronized keyword. When we call encapsulated third-party APIs, the caller may only know the public interface method based on the "interface-oriented design" principle, but I don't know whether the implementation class actually implements it as a synchronization method. This unknown nature may have potential risks.

Suppose there is an interface like this:

public interface GlobalObjectCache {public Object get(String id);}

If the interface method get () is implemented as follows:

public synchronized Object get(String id){Object obj = items.get(id); if(obj == null) {obj = create(id); items.put(id, obj);} return obj;}protected Object create(String id) {//...}

This code is very simple. When the caller tries to obtain the target object based on the id, the caller first searches for the object in the Cache and returns the object directly if any. Otherwise, the target object is obtained through the create () method, then store it in the Cache. The create () method is a non-final method defined by this class. It executes the database query function. Now, we assume that users who use this class have extended it. For example, define the RemoteAvailabilityCache class to derive the class, override the create () method, and change the original local call to remote call. The problem occurs. Because the create () method is used for remote call, when the server is busy, remote call requests may be blocked. Because the get () method is a synchronous method, only one thread can access it at a time in the method body until the method is executed to release the lock. Now the create () method is blocked, causing other threads that attempt to call the get () method of the RemoteAvailabilityCache object to be blocked. In this case, the system may crash.

Of course, we can think that this expansion itself is unreasonable. But from the design perspective, it does not violate the Liskove replacement principle. From the interface perspective, its behavior has not changed, but the implementation has changed. If it is not a synchronous method, the blocking of a calling thread will not affect other calling threads, and the problem can be avoided. Of course, the synchronization method here is reasonable because only the synchronous method can ensure that the read to the Cache supports concurrency. This example is provided in the book to illustrate the potential danger of the synchronization method, prompting us to consider carefully when writing code.