создание уникального идентификатора запроса для каждого запроса с использованием метода timemillis в Servlet

Question

Я работаю над сервлетом, где мне нужно предоставить уникальный запрос каждому запросу и сохранить каждый параметр запроса в таблице аудита. Меня беспокоит работа с грязным чтением в таблицах базы данных, если я пытаюсь увеличить значение, просмотрев таблицу для предыдущего идентификатора. Я хочу знать, если при использовании времени в миллисекундах, когда запрос будет отправлен в сервлет, чтобы решить эту проблему. Я боюсь, если какой-либо другой запрос поступит из другого места географии в тот же самый момент для того же сервлета, чтобы java.lang.System.currentTimeMillis() будет таким же для другого входящего запроса. Причина, по которой я поставил такое сомнение, я считаю, что многопоточность поведения сервлета принимает запрос одновременно, а затем охватывает циклы процессора для каждого запроса на основе некоторого алгоритма.

Answer 1

System.currentTimeMillis() не гарантирует уникальность при вызове нескольких потоков. Столкнувшись с такой ситуацией в прошлом я использовал AtomicLong для создания уникальных идентификаторов - это класс getAndIncremenet должен быть безблокировочным (и, следовательно, достаточно эффективно) на большинстве виртуальных машин

public class IdUtil { 
    private static final AtomicLong counter = new AtomicLong(System.currentTimeMillis()); 

    // return a single id 
    public static long getId() { 
     return counter.getAndIncrement(); 
    } 

    // return a block of ids 
    public static Queue<Long> getIds(long span) { 
     long max = counter.addAndGet(span); 
     Queue<Long> queue = new ArrayDeque<>(span); 
     for(int i = max - span; i < max; i++) { 
      queue.add(i); 
     } 
    } 
} 

Answer 2

Даже синхронизируется неправильно. Вы можете получить одинаковый идентификатор для двух запросов, очень близких по времени. Лучше использовать случайный длинный или последовательный номер.

private static final Random r = new Random(); // <- shared resource 
// ... 
long id = r.nextLong(); 

или

private static final AtomicLong counter = new AtomicLong(System.currentTimeMillis()); // <- shared resource 
// ... 
long id = counter.getAndIncrement(); 

counter инициализируется миллисекунд, так что не обеспечивает ту же последовательность ID после перезапуска программы.