为什么Properties.list在打印前复制表？

Question

Here's the implementation of Properties.list from JDK:

public void list(PrintWriter out) {
    out.println("-- listing properties --");
    Hashtable<String,Object> h = new Hashtable<>();
    enumerate(h);
    for (Enumeration<String> e = h.keys() ; e.hasMoreElements() ;) {
        String key = e.nextElement();
        String val = (String)h.get(key);
        if (val.length() > 40) {
            val = val.substring(0, 37) + "...";
        }
        out.println(key + "=" + val);
    }
}

What are the lines

Hashtable<String,Object> h = new Hashtable<>();
enumerate(h);

for? Couldn't it just use original table instead of making a copy and reading data from it?

Answer 1

这是允许线程安全迭代的常用习惯用法（即，如果另一个线程在循环期间修改哈希表，则不会出现ConcurrentModificationException ）。

Answer 2

The list() method is not synchronized.
So any invocation (even those synchronized) on the Properties instance during list() invocation may break the state of the object and result to an exception or a broken logic.

Suppose that instead using an intermediate Properties instance, we iterate directly on the Properties instance it would be no thread safe

Suppose that we have two threads : Thread A that calls this list() method and Thread B that calls remove() on a same Properties instance.

This code in the list() method has multiple race conditions.

To illustrate, we could use this snippet of the list() method :

   String key = e.nextElement();
   String val = (String)h.get(key);
   if (val.length() > 40) {

Suppose the thread A is paused after this instruction :

 String key = e.nextElement();  

The thread B is resumed and invokes instance.remove() with as parameter the object associated to the key retrieved by the Thread A

Then when the thread A is resumed it goes to the next instruction :

 String val = (String)h.get(key);

The value doesn't exist any longer.

The next instruction raises an exception as val is null :

    if (val.length() > 40) {

Answer 3

This is an optimization for multithreaded applications.

A Properties object is meant to be thread safe, so they had to either make the method synchronized (which is a bad idea since writing to a PrintStream can block for a long time, holding the lock), or they can just quickly copy the contents to a new hashtable within a synchronized block ( enumerate is synchronized), and then printing the items of the copy, without holding a lock.