RetainCount == BAD

retainCount é tabu, não confiável, imprevisível e, em geral, não deve ser usado. Eu não o uso em nenhum lugar do meu código, mas eu o vi em uma classe que uso de maneira interessante.

Eu tenho uma classe que executa um thread que é executado indefinidamente até que o segmento é cancelado. O problema é que o encadeamento aumenta a contagem de retenções do proprietário, no meu caso, a classe que o instanciou. Então, mesmo que eu tenha acabado de usar essa classe, essa instância ainda vai ficar pendurada, a menos que quem quer que esteja gerenciando minha classe também tenha o conhecimento necessário para encerrar o segmento. Essa é uma solução, mas é isso que encontrei no código.

<code>- (oneway void)release
{
    // This override allows allows this object to be dealloced 
    // by shutting down the thread when the thread holds the last reference.
    // Otherwise, the object will never be dealloc'd
    if (self.retainCount == 2)
    {
        [self quitDispatchThread];
    }

    [super release];
}
</code>

Esta é uma solução inteligente, mas não tenho certeza do que pensar sobre isso. Ele substitui a liberação na classe e verifica se a contagem de retenções é 2. Em outras palavras,ele verifica se o fio é a única coisa que mantém meu objeto vivo (já que a contagem de retenções está prestes a ser decrementada de 2 para 1) e, se estiver, termina o encadeamento (quitDispatchThread irá bloquear até que o segmento seja terminado).

Assim...

Você pode confiar no retainCount para ver se é um?

Geralmente as pessoas dizem para evitarretainCount porque você não sabe se há algumas autoreleases lá. No entanto, se o retentionCount é um, então eu sei de fato que apenas o segmento está mantendo-o vivo e eu não tenho que se preocupar que o retainCount pode estar desligado devido a algumas autoreleases, etc ...

O que há de errado com esse código?

Eu estava prestes a removê-lo, mas na verdade parece fazer sentido. Outros objetos não precisam ter consciência de que minha classe está executando um thread. Outros objetos podem com segurançaretain erelease ou até mesmoautorelease o objeto que possui o encadeamento sem ter que se preocupar em encerrar o encadeamento porque ele cuida de si mesmo.

Este código realmente parece limpo, o que me surpreende.

Edit :: NSThread está retendo meu objeto

A contagem de retenção do meu objeto é aumentada pelo fato de eu estar usando o NSThread. Meu objetivo é otarget e aselector é o método no qual o encadeamento é executado.

initWithTarget: selector: object:

Retorna um objeto NSThread inicializado com os argumentos fornecidos.

(id) initWithTarget: (id) seletor de destino: objeto seletor (SEL): argumento (id)

Parâmetros

alvo

O objeto para o qual a mensagem especificada pelo seletor é enviada.

seletor

O seletor da mensagem a ser enviada para o destino. Este seletor deve ter apenas um argumento e não deve ter um valor de retorno.

argumento

O único argumento passou para o alvo. Pode ser nulo.

Valor de retorno

Um objeto NSThread foi inicializado com os argumentos fornecidos.

Discussão

Para aplicativos não coletados por coleta de lixo, o seletor de método é responsável por configurar um conjunto autorelease para o segmento recém-desanexado e liberá-lo antes de sair. Os aplicativos coletados por coleta de lixo não precisam criar um pool de autorelease.

Os objetos alvo e argumento são retidos durante a execução do encadeamento desanexado. Eles são liberados quando o thread finalmente sai.