JDK 컬렉션에서 다음과 유사한 단어를 자주 볼 수 있습니다.
예를 들어 ArrayList:
注意,迭代器的快速失败行为无法得到保证,因为一般来说,不可能对是否出现不同步并发修改做出任何硬性保证。快速失败迭代器会尽 最大努力抛出 ConcurrentModificationException。因此,为提高这类迭代器的正确性而编写一个依赖于此异常的程序是错误的做法:迭 代器的快速失败行为应该仅用于检测 bug。
HashMap:
注意,迭代器的快速失败行为不能得到保证,一般来说,存在非同步的并发修改时,不可能作出任何坚决的保证。快速失败迭代器尽最大 努力抛出 ConcurrentModificationException。因此,编写依赖于此异常的程序的做法是错误的,正确做法是:迭代器的快速失败行为应 该仅用于检测程序错误。
"빠른 실패"가 이 두 단락에서 반복적으로 언급됩니다. 그렇다면 "빠른 실패" 메커니즘은 무엇입니까?
"빠른 실패"는 빠른 실패이며, 이는 Java 컬렉션에 대한 오류 감지 메커니즘입니다. 여러 스레드가 컬렉션에 대한 구조적 변경을 수행하면 빠른 실패 메커니즘이 발생할 수 있습니다. 확실하지는 않지만 가능하다는 것을 기억하십시오. 예: 두 개의 스레드(스레드 1, 스레드 2)가 있다고 가정합니다. 스레드 1이 Iterator를 통해 세트 A의 요소를 순회하고 있다고 가정합니다. 어떤 시점에서 스레드 2는 세트 A의 구조를 수정합니다. 간단히 컬렉션 요소의 내용을 수정하면 프로그램은 이때 ConcurrentModificationException 예외를 발생시켜 빠른 실패 메커니즘을 생성합니다.
1.fail-fast의 예
public class FailFastTest { private static List<Integer> list = new ArrayList<>(); /** * @desc:线程one迭代list * @Project:test * @file:FailFastTest.java * @Authro:chenssy * @data:2014年7月26日 */ private static class threadOne extends Thread{ public void run() { Iterator<Integer> iterator = list.iterator(); while(iterator.hasNext()){ int i = iterator.next(); System.out.println("ThreadOne 遍历:" + i); try { Thread.sleep(10); } catch (InterruptedException e) { e.printStackTrace(); } } } } /** * @desc:当i == 3时,修改list * @Project:test * @file:FailFastTest.java * @Authro:chenssy * @data:2014年7月26日 */ private static class threadTwo extends Thread{ public void run(){ int i = 0 ; while(i < 6){ System.out.println("ThreadTwo run:" + i); if(i == 3){ list.remove(i); } i++; } } } public static void main(String[] args) { for(int i = 0 ; i < 10;i++){ list.add(i); } new threadOne().start(); new threadTwo().start(); } }
실행 결과:
ThreadOne 遍历:0 ThreadTwo run:0 ThreadTwo run:1 ThreadTwo run:2 ThreadTwo run:3 ThreadTwo run:4 ThreadTwo run:5 Exception in thread "Thread-0" java.util.ConcurrentModificationException at java.util.ArrayList$Itr.checkForComodification(Unknown Source) at java.util.ArrayList$Itr.next(Unknown Source) at test.ArrayListTest$threadOne.run(ArrayListTest.java:23
2.fail-fast의 원인
위의 예와 설명을 통해 처음에는 Fail-Fast의 원인이 무엇인지 알았습니다. 프로그램은 컬렉션을 반복할 때 스레드가 컬렉션에 대한 구조적 수정을 수행합니다. 이때 반복자는 ConcurrentModificationException 예외 정보를 발생시켜 빠른 실패를 발생시킵니다.
빠른 실패 메커니즘을 이해하려면 먼저 ConcurrentModificationException 예외를 이해해야 합니다. 이 예외는 메소드가 객체의 동시 수정을 감지했지만 그러한 수정을 허용하지 않는 경우 발생합니다. 동시에, 이 예외는 객체가 다른 스레드에 의해 동시에 수정되었음을 항상 나타내지는 않는다는 점에 유의해야 합니다. 단일 스레드가 규칙을 위반하면 예외가 발생할 수도 있습니다.
반복자의 빠른 실패 동작이 보장되지 않고 오류가 발생한다고 보장하지 않는다는 것은 사실이지만 빠른 실패 작업은 최선을 다해 ConcurrentModificationException 예외를 발생시키므로 정확성을 향상시키기 위해 이러한 작업 중 프로그램이 이 예외에 의존하는 것은 실수입니다. 올바른 접근 방식은 다음과 같습니다. ConcurrentModificationException은 버그를 감지하는 데에만 사용해야 합니다. 아래에서는 ArrayList를 예로 사용하여 빠른 실패의 이유를 추가로 분석하겠습니다.
앞서 우리는 반복자를 작동할 때 빠른 실패가 생성된다는 것을 알고 있습니다. 이제 ArrayList에서 iterator의 소스 코드를 살펴보겠습니다.
private class Itr implements Iterator<E> { int cursor; int lastRet = -1; int expectedModCount = ArrayList.this.modCount; public boolean hasNext() { return (this.cursor != ArrayList.this.size); } public E next() { checkForComodification(); /** 省略此处代码 */ } public void remove() { if (this.lastRet < 0) throw new IllegalStateException(); checkForComodification(); /** 省略此处代码 */ } final void checkForComodification() { if (ArrayList.this.modCount == this.expectedModCount) return; throw new ConcurrentModificationException(); } }
위 소스 코드에서 iterator가 next() 및 delete() 메서드를 호출할 때 checkForComodification() 메서드를 호출하는 것을 볼 수 있습니다. 주로 modCount == ExpectModCount?를 감지하는 것입니다. 그렇지 않은 경우 ConcurrentModificationException 예외가 발생하여 빠른 실패 메커니즘이 생성됩니다. 따라서 빠른 실패 메커니즘이 발생하는 이유를 파악하려면 왜 modCount != ExpectModCount인지, 해당 값이 언제 변경되었는지 파악해야 합니다.
expectedModCount는 Itr에 정의되어 있습니다. int ExpectModCount = ArrayList.this.modCount; 따라서 해당 값은 수정할 수 없으므로 변경되는 것은 modCount입니다. modCount는 AbstractList에 정의되어 있으며 전역 변수입니다.
protected transient int modCount = 0;
그러면 언제, 어떤 이유로 변경됩니까? ArrayList의 소스 코드를 살펴보세요.
public boolean add(E paramE) { ensureCapacityInternal(this.size + 1); /** 省略此处代码 */ } private void ensureCapacityInternal(int paramInt) { if (this.elementData == EMPTY_ELEMENTDATA) paramInt = Math.max(10, paramInt); ensureExplicitCapacity(paramInt); } private void ensureExplicitCapacity(int paramInt) { this.modCount += 1; //修改modCount /** 省略此处代码 */ } public boolean remove(Object paramObject) { int i; if (paramObject == null) for (i = 0; i < this.size; ++i) { if (this.elementData[i] != null) continue; fastRemove(i); return true; } else for (i = 0; i < this.size; ++i) { if (!(paramObject.equals(this.elementData[i]))) continue; fastRemove(i); return true; } return false; } private void fastRemove(int paramInt) { this.modCount += 1; //修改modCount /** 省略此处代码 */ } public void clear() { this.modCount += 1; //修改modCount /** 省略此处代码 */ }
위의 소스 코드에서 ArrayList의 추가, 제거, 삭제 메소드와 상관없이 ArrayList 요소의 수를 변경하는 한 modCount는 변경된다는 것을 알 수 있습니다. . 따라서 여기서 예상ModCount 값과 modCount의 변경 사항이 동기화되지 않아 둘 사이에 불평등이 발생하여 빠른 실패 메커니즘이 발생한다고 사전에 판단할 수 있습니다. Fail-Fast의 근본 원인을 알면 다음과 같은 시나리오를 가질 수 있습니다.
두 개의 스레드(스레드 A, 스레드 B)가 있는데, 그 중 스레드 A는 목록 순회를 담당하고 스레드 B는 목록을 수정합니다. 스레드 A가 목록을 순회하는 어느 시점에서(이 시점에서 ExpectModCount = modCount=N) 스레드가 시작되고 동시에 스레드 B가 요소를 추가합니다. 이는 modCount의 값이 변경됨을 의미합니다(modCount + 1 = N + 1). 스레드 A가 계속해서 다음 메소드를 순회하면서 실행하면, ExpectModCount = N, modCount = N + 1임을 checkForComodification 메소드에 통보하는데, 이때 ConcurrentModificationException 예외가 발생하여 실패하게 됩니다. -빠른 메커니즘.
그래서 지금까지 우리는 Fail-Fast의 근본 원인을 완전히 이해했습니다. 원인을 알고 나면 해결책을 찾는 것이 더 쉽습니다.
3.빠른 실패에 대한 해결책
이전의 예제와 소스 코드 분석을 통해 기본적으로 실패의 메커니즘을 이해했다고 생각합니다. 이제 그 원인에 대한 해결책을 제안하겠습니다. 여기에는 두 가지 해결 방법이 있습니다.
해결 방법 1: 순회 프로세스 중에 modCount 값 변경과 관련된 모든 위치에 동기화를 추가하거나 Collections.synchronizedList를 직접 사용하면 문제를 해결할 수 있습니다. 그러나 추가 및 삭제로 인한 동기화 잠금으로 인해 순회 작업이 차단될 수 있으므로 권장되지 않습니다.
옵션 2: CopyOnWriteArrayList를 사용하여 ArrayList를 대체합니다. 이 솔루션을 권장합니다.
위 내용은 빠른 실패 메커니즘의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!