clear () impl no LinkedList do Java
-
05-09-2019 - |
Pergunta
Temo que esta é uma pergunta muito estúpida, mas aqui vai:
Por que o método claro na implementação LinkedList padrão do Java incomodar a caminhar na lista e solte todos os nós? Porque não basta desprender o cabeçalho e deixar o resto da lista ligada? - o GC vai buscá-la de qualquer maneira, não
Aqui está o método:
/**
* Removes all of the elements from this list.
*/
public void clear() {
Entry<E> e = header.next;
while (e != header) {
Entry<E> next = e.next;
e.next = e.previous = null;
e.element = null;
e = next;
}
header.next = header.previous = header;
size = 0;
modCount++;
}
Por que anda ele? Porque não basta pular para header.next = header.previous = header;
?
Melhor eu posso figura é que ajuda a GC ...? Este link http://java.sun.com /docs/books/performance/1st_edition/html/JPAppGC.fm.html#997442 tipo de sugere que.
TIA ...
Solução
Seus garante método que, mesmo se outro código ainda mantém referências a nós em particular, os outros nós serão GC'ed.
De outro modo, mesmo uma única referência externo para um dos nós impediria a cadeia inteira de ser recolhida.
Além disso, outras operações na lista pode estar acontecendo simultaneamente (por exemplo, pontos de vista através subList()
ou Collections.unmodifiableList()
, iteradores), e isso garante que essas coisas perceber a lista como "vazio" imediatamente.
Outras dicas
IIRC, esta foi uma mudança feita em JDK6 para auxiliar o desempenho de determinados (gerações) algoritmos de GC. Muitas vezes, a própria List
e nós mais velhos vão estar em uma geração mais velha do que alguns dos outros nós. As gerações mais jovens vão se recolheu mais frequentemente, com o resultado que os jovens nós são copiados sobre antes de ser descoberto que todos os nós são lixo.
Por isso, é uma otimização de desempenho menor. otimização de desempenho de memória é um pouco estranho em que muitas vezes não é o código que está causando o problema que está tomando o tempo para executar.
Eu estava apenas especulando sobre esta questão no meu blog de desenvolvimento do jogo. Obrigado pela resposta. Eu diria que a exposição nó era um subsídio projeto questionável. É também esboçado que visões alternativas da lista (iteradores e tal) iria contar com nó desvinculando a falhar-rápido. Em vez de depender este comportamento efeito colateral, sub-pontos de vista sobre a lista deve ser verificando a contagem de modificação. Em qualquer caso, não vejo por que está preso com ele agora.
O código fonte do java.util.LinkedList em http://developer.classpath.org/doc/java/util/LinkedList-source.html sugere que você pode simplesmente definir o primeiro e último elementos para null.
É claro que se você tende a ser mais protetor, você pode percorrer a coisa toda. Eu pessoalmente acho que isso pode ser uma tarefa muito caro se a sua lista de espera vários milhares de elementos.