Problema com sincronização de Vector

O vetor tem todos métodos sincronizados.

Isso só significa que seus métodos são atômicos, isso é, uma thread não poderá dar remove enquanto outra estiver fazendo add. Mas a segurança para por aí. A classe não protege contra coisas que acontecem “entre” a chamada de dois métodos. Por exemplo:

v.add("Vinicius");
v.add("João"); //Pode ter havido preempção antes do add("João");

No seu caso, como é a maioria das vezes, ainda é preferível usar o List no lugar do Vector e sincronizar os métodos da sua classe que está usando o List.

Aliás, dificilmente é uma boa escolha trocar List pelo Vector. Até porque, é possível gerar uma versão sincronizada da lista, só nos pontos onde a sincronização é necessária. Basta fazer:

List<SuaClasse> suaListaSincronizada = Collections.synchronizedList(suaLista);

Isso cria um wrapper na lista original, com a capacidade de sincronização.

Agora, se vc sincronizou todos os pontos de acesso, você deve se certificar que:

1. Seu código esteja certo;
2. Você não tenha esquecido de sincronizar locais menos óbvios;
3. Não seja uma situação de exceção (como tentar dar getSelected() numa lista que não tem elemento selecionado).

Tente também seguir o stack trace, e ver o pq da exceção.

Valeu mas resolvi abdicar dos recursos da Collection para usar recursos primitivos !

No caso em questão eu fazia o seguinte !
Quando o botão que disparava a thread era executado ele pegava os índices dos objetos selecionados e então copiava esses objetos para um ListIterator.De acordo com que o iterator era percorrido no momento do changeList() ele pedia pra jList devolver o indice daquele objeto e então fazia o cambio. Não se existe falha nessa lógica . Decidi usar o ListIterator ao invés do Iterator pelo recurso do previous(), se é que eu também não sei se existe alguma diferença relevante entre eles para o fato em questão (o previous() era fundamental para atender a uma interação com o usuário na qual ele pode optar por persistir em caso de erros).

o erro era disparado aqui :

public synchronized E elementAt(int index) {
	if (index >= elementCount) {
	    throw new ArrayIndexOutOfBoundsException(index + " >= " + elementCount);
	}

        return (E)elementData[index];
    }

Bem , principalmente por questão de tempo eu não pude investigar o real motivo da causa !
mudei o esquema pro bom e velho laço FOR !

Saberia me dize se perco em algum ponto por causa disso ?
Eu me acostumei tanto a usar Iterator nas classes collection que
nem parei pra pensar nisso !

Você tem perdas se sua lista for um LinkedList.

Mas o que você fez você somente está escondendo um problema real. Se eu fosse você, mantinha o iterator e procurava mesmo sincronizar direto o seu programa.
É melhor ter um comportamento mais determinístico e problemático do que um erro que age silenciosamente, e vai só aparecer esporadicamente, nas mãos do seu cliente.

Kra , você tem mesmo razão !
vai ser preciso uma analise mais minuciosa !
ja passei por muita coisa pior , e provavelmente vou acabar
conseguindo resolver isso , pensando bem , vai valer a pena
tentar, valeu pelas dicas .

Geralmente, basta sincronizar os trechos onde a lista é acessada.

Se está difícil identificar todos os pontos, crie uma classe que encapsula essa lista, dê a ela os métodos necessários e troque a lista por essa classe.
Aí fica garantido.

Acho que solucionei o problema !
Na verdade eu sabia o que fazer , tanto é que eu postei o código aqui no tópico do jeito certo !
Acho que meu sub-quociente esta mais atento que eu ! :lol:
Eu juro que não me lembro de edita-lo pra postar , é até engraçado , mas não sei porque eu estava
dando repaint() nas jList !

o código na verdade era assim :

public void rebuildjList1()
    {
    jList1.setListData(data);
    jList1.repaint();
    }
    
    public void rebuildjList2()
    {
    jList2.setListData(data2);
    jList1.repaint();
    }

Fiz um bom numero de testes e aparentemente o erro sumiu ! além do mais faz sentido
que enquanto a minha thread movia os elementos a thread AWT tentava repintar os componetes !
acredito que era ai onde ocorria a divergência , pois provavelmente a AWT ficava pra trás !
e entrava no Vector atrasada , como você bem relembrou isso poderia ocorrer
no meio de uma remoção da outra thread .

OBS : Putzz que cagada eu tava fazendo ,pior do que eu pensava , acabei de ver um absurdo maior ainda que passou batido , a Jlist1 tava recebendo repaint 2 vezes , um em cada rebuild!

Kra valeu mesmo , se você não me desse um toque pra insistir em encontrar o problema ia ficar esse
erro grotesco programa , sabe-se lá quando eu iria notar isso !

PARABÉNS!

E isso está se tornando um hábito cada vez maior, pelo que vejo aqui no GUJ e em outros fóruns. O programador, ao invés de entender e corrigir o problema, tenta contorna-lo, sem entender exatamente os fatores que levaram ao erro. Já vi muita gente aqui no GUJ fazendo isso, e muita gente até sugerindo uma resolução de dúvida com gambis desse tipo…

É uma prática que leva a programas instáveis e difíceis de corrigir. Afinal, vc está trocando um erro evidente por um obscuro… Uma péssima troca, diga-se de passagem.

A gente tem sempre que lembrar que quem mais usa o nosso sistema é o cliente. E, portanto, é com ele que esse erro vai se manifestar… E aí, será pressão do chefe, horas extras e noites perdidas de sono (quem mandou vc deixar o erro menos evidente, bobão?). Realmente não vale a pena.

Mas parabéns cara! O único jeito de aprender bem threads é com pepinos como esse… não se engane…
eu já perdi muitas noites de sono com bugs sinistros causados pelo paralelismo.