Personally understand, if something is wrong, please correct me.
1. use StringBuilder to replace StringBuffer
The main difference between StringBuilder and StringBuffer is one that is not thread-safe, one thread-safe (the method adds a synchronized keyword before, so performance is somewhat lower).
The personal understanding of thread safety is that in a multithreaded environment, a shared resource (or a critical resource) can be properly handled, so that the program normally runs to the desired behavior of thread safety and is not thread safe.
A shared resource is a class variable or instance variable that is accessed by multiple threads and may be modified, and local and method parameter variables are not shared resources.
instance variables or class variables such as the traditional Java servlet (single instance multithreading, which requests the servlet to start a thread for each browser) are shared resources, and you must consider the possibility of being modified by multiple threads at the same time when you are working on shared resources.
The synchronized mechanism is introduced in Java to ensure that only one thread at a time handles the shared resource. The content order of the data is consistent with the processing order of multiple threads, that is, thread-safe.
Based on this we will find that in most cases of web development it is possible to use StringBuilder instead of the jdk1.4 before the StringBuffer.
When using STRUTS2, Struts2 generates a new instance (multiple instance single-threaded) for each request, and there is no shared resource that can be accessed by multiple threads, regardless of thread security. So Struts2 is generally said to be thread-safe.
STRUTS1 is not thread-safe, and multiple threads need to be considered to read and write shared resource situations.
The ArrayList and Vector,hashmap and Hashtable situations are similar to those of StringBuilder and StringBuffer.
To ensure thread safety, you can also choose another alternative ThreadLocal
Threadlocal Mechanical Engineer A copy of a resource for each line, avoiding synchronization overhead and deadlock generation.
Threads operate on each other's own resources and do not affect each other.
2. using dynamic parameter characteristics
outside: Java parameter passing is value delivery, not reference delivery (see core Java)
For example, define a method that sets the value of the PreparedStatement according to the number of parameters
Public PreparedStatement preparestatement (Connection conn, String sql,object ... objs) {PreparedStatement PS = null; try { PS = conn.preparestatement (SQL); for (int i = 1; I <= objs.length i++) {ps.setobject (I, objs[i-1]);} catch (Exception e) {e.printstacktrace ();} return PS; }
We can call this method this way:
String sql = "SELECT * from t where t.a =?" and t.b =? and t.c=? "; Object[] values ={"XXX", 123, "456"}; Preparestatement (conn,sql,values);//Way One preparestatement (conn,sql, "xxx", 123, "456");//mode two String sql = "SELECT * FROM T" "; Preparestatement (conn,sql);//mode three String sql = "SELECT * from T where t.a=?"; Preparestatement (conn,sql, "xxx");/Mode Four
Isn't it convenient? Before this new feature is present, we may have to fill in the unnecessary parameter passes with NULL.