Class in Java collection about thread safety

The classes in the Java collection are thread-safe

Thread safe class

In the collections framework, some classes are thread-safe, and these are all present in jdk1.1. After jdk 1.2, there are many, many non-thread-safe classes. Here are some of these thread-safe synchronized classes:

vector: it has an additional synchronization mechanism (thread safety) than arraylist, which is now less recommended because it is less efficient. In web applications, especially front page, efficiency (page response speed) is often a priority.

statck: stack class, first in, then out

hashtable: one more thread safe than hashmap

enumeration: enumeration, equivalent to an iterator

Other than that, there are non-thread-safe classes and interfaces.

Thread-safe classes have their methods synchronized and can only be accessed one at a time. It's a heavyweight, it's inefficient.

Other:

1. Differences between hashtable and hashmap

hashtable is thread safe, that is, hashtable's methods all provide synchronization. hashmap is not thread safe, that is, it does not provide synchronization. hashtable does not allow inserting null values,hashmap does!

2. What if multiple threads concurrently modify a set

Use the old Vector/Hashtable class

StringBuffer is thread safe, while StringBuilder is thread unsafe. Without a deep understanding of security and insecurity, it is easy to create the illusion that if all operations for StringBuffer are thread-safe, however, the thread-safe guarantee that Java gives you is that its methods are executed exclusively, not in the case of multiple calls to the object itself. Look at the example below, a data member in StringBufferTest contents it is used to extend, it every time 1 append is thread-safe, but many times append combination is not thread-safe, the output is not controllable, but if the keyword synchronized log and getContest method, then the result will become very organized, if change StringBuider even append to 1 and a half, it will also give way to other threads on the basis of the operation:

public class StringBufferTest {
  private StringBuffer contents = new StringBuffer();
  public void log(String message){
   contents.append(System.currentTimeMillis());
   contents.append("; ");
   contents.append(Thread.currentThread().getName());
   for(int i=0;i<10000;i++){
    contents.append(i);  
     contents.append(message);  //append Itself is thread safe for modification contents Is not accessible by other threads. 
     contents.append("\n");
   }
   contents.append("\n\n");
  }
  public void getContents(){
   System.out.println(contents);
  }
}

class RunThread extends Thread{
  String message;
  StringBufferTest buffer;
  public RunThread(StringBufferTest buffer, String message){
   this.buffer = buffer;
   this.message = message;
  }
  public void run(){
   while(true){
     buffer.log(message);
     buffer.getContents();
   }
  }
  public static void main(String[] args) {
   StringBufferTest ss = new StringBufferTest();
   new RunThread(ss, "you").start();
   new RunThread(ss, "me").start();
   new RunThread(ss, "she").start();
  }
}

The StringBuilder and StringBuffer methods are 1-mode, 1 multithreaded and 1 single-threaded. Thread calls the append method of 1StringBuffer, which has nothing to do with whether it is thread-safe or not, unless your result is that append's series 1 string is corrupted, that means it is thread-unsafe. Thread safety is when only one thread accesses a critical resource at any given time. Thread-safe does not mean that its series 1 operations are synchronous, just that it does not allow other threads to change when it executes a method. Whether a class is thread-safe or not depends on the fact that multiple threads are running at the same time. These threads may execute a method at the same time. But the result of each run is the same as the result of a single threaded execution, so it can be said to be thread-safe. Because the log method is not locked, each of the append locks can now get an cpu execution fragment after the append lock is released.

But don't get the wrong idea about multithreaded security:

 public String toString(){
   StringBuffer buffer = new StringBuffer();
   buffer.append('<');
   buffer.append(this.name);
   buffer.append('>');
   return buffer.toString();
  }

This code is fully thread-safe, a variable defined inside the method that is created when each thread enters! There are no thread safety issues involved. Usually involves the system security variable 1 is the member variable! The internal implementation of stringBuffer itself is field safe! Thread safety that's the functionality that the class itself provides that is safe. That is, if you provide the insertion of 1 string, then the string insertion is safe, but if you want to insert 2 strings, the order of the two is up to you, and if there is any other insertion error in between you don't care about the class, it's your own code.

Thank you for reading, I hope to help you, thank you for your support of this site!