Respostas que geralmente eu daria…

1. Quando te vêem deitado, de olhos fechados, na sua cama, com a luz apagada e te perguntam:
– Você tá dormindo?
– Não, to treinando pra morrer!

2. Quando a gente leva um aparelho eletrônico para a manutenção e o técnico pergunta:
– Ta com defeito?
– Não, é que ele estava cansado de ficar em casa e eu o trouxe para passear.

3. Quando está chovendo e perc ebe m que você vai encarar a chuva, perguntam:
– Vai sair nessa chuva?
– Não, vou sair na próxima.

4. Quando você acaba de levantar, aí vem um idiota (sempre) e pergunta:
– Acordou?
– Não.. Sou sonâmbulo!

5. Seu amigo liga para sua casa e pergunta:
– Onde você está?
– No Pólo Norte! Um furacão levou a minha casa pra lá!

6. Você acaba de tomar banho e alguém pergunta: (BOA)
– Você tomou banho?
– Não, mergulhei no vaso sanitário!

7. Você tá na frente do elevador da garagem do seu prédio e chega um que pergunta: (ÓTIMA)
– Vai subir?
– Não, não, to esperando meu apartamento descer pra me pegar.

8. O homem chega à casa da namorada com um enorme buquê de flores. Até que ela diz:
– Flores?
– Não! São cenouras.

9. Você está no banheiro quando alguém bate na porta e pergunta: (Magnífica!!!!!!!)
– Tem gente?
– Não! É o cocô que está falando!

10. Você chega ao banco com um cheque e pede pra trocar: (MUITO BOA)
– Em dinheiro? ?
– Não, me dá tudo em clipes…

Memory leak em Java: O que é, como se faz e como evitar

Ao contrário do que muitas pessoas pensam, uma aplicação escrita em Java pode sim apresentar problemas de vazamento de memória, termo comumente conhecido por memory leak. Infelizmente, um grande número de programadores Java acha que memory leak é coisa de C/C++ e que o garbage collector do Java resolve esse problema completamente. Neste artigo pretendo mostrar que o garbage collector, apesar de ser funcionar muito bem, não é capaz de fazer mágica.

Memory leak significa exatamente o que o seu nome diz: vazamento de memória.
Ele pode ser de dois tipos:
1) Blocos de memória: estão alocados e disponíveis para serem usados pela aplicação, mas não são acessíveis porque a aplicação não tem nenhum ponteiro* apontando para essa área de memória. Logo, estes blocos de memória não podem nem ser usados nem pela aplicação e nem por outros processos.
2) Blocos de memória: possuem dados que poderiam ser liberados por serem inacessíveis e que, por “esquecimento”, ainda são referenciados no código mesmo sem estarem sendo usados, não podendo ser liberados.

A situação 1 é muito comum em C/C++. Aloca-se uma quantidade de memória usando a função malloc*, por exemplo, e na seqüência o programador faz com que o ponteiro para essa área de memória passe a apontar para outro local, perdendo a referência inicial. Em Java este tipo de memory leak não ocorre, pois o garbage collector é capaz de detectar blocos de memória alocados e não referenciados e liberá-los para uso posterior.

É na situação 2 que mora o problema. Mas antes de explicar como esse problema pode ocorrer e como evitá-lo, vamos entender um pouco mais como funciona o garbage collector do Java.
1. Um ponteiro é uma variável que aponta para um endereço de memória. É um termo bastante comum em C/C++ e engana-se quem acha que Java não possui ponteiros. Quando um objeto é criado usando new, a variável que recebe o objeto é, na verdade, um ponteiro que aponta para um endereço de memória que contém o objeto.
2. A função malloc() faz parte da API do C. Sua função é alocar a quantidade de memória desejada (fornecida como parâmetro). O retorno desta função é um ponteiro para a área de memória recém criada.

O Papel do garbage collector
Uma das grandes vantagens do Java sobre linguagens de programação de mais baixo nível é a presença do garbage collector (coletor de lixo). A função do dele é vasculhar a memória atrás de blocos alocados que não tenham mais como ser referenciados pela aplicação. Quando o garbage collector se depara com uma situação desse tipo, ele desaloca a memória, tornando-a disponível para ser usada novamente pela aplicação.

Ver o garbage collector funcionando no Java é muito fácil. Observe este código:
public static void main(String[] args) throws Exception {
int[] array = null;
while(true) {
array = new int[1000];
System.out.println(“Bytes livres: “+ Runtime.getRuntime().freeMemory());
Thread.sleep(200);
}
}

Este código fica executando em um loop infinito. A cada iteração do loop, um array de 1000 posições de inteiros é criado. Cada vez que o loop é executado, é mostrada a quantidade de bytes livres. Num primeiro momento você pode pensar: “esta aplicação vai acabar com a memória da JVM?”. Mas na verdade não é isso que acontece. Ao executar o programa, em determinado momento você vai observar a seguinte saída:

Bytes livres: 1530520
Bytes livres: 1530520
Bytes livres: 1530520
Bytes livres: 1526504
Bytes livres: 1522488
Bytes livres: 1518472
Bytes livres: 1514456
Bytes livres: 1510440
Bytes livres: 1912792
Bytes livres: 1912792
Bytes livres: 1908776
Bytes livres: 1904760
Bytes livres: 1900744
Bytes livres: 1896728
Bytes livres: 1892712

A memória estava acabando e, repentinamente, ela aumentou. A explicação disso é simples. Quando o loop é executado, é criado o array. Na próxima iteração do loop, o array criado na iteração anterior não é referenciado por mais ninguém (perceba que a variável array deixou de apontar para o array antigo e passou a apontar para o novo array, fazendo com que o array antigo ficasse inacessível). Em determinado momento, a JVM percebe a queda da memória disponível e coloca o garbage collector em execução. O garbage collector então descobre que essa memória que foi sendo alocada no decorrer dos loops está inacessível e a libera. É neste momento que podemos perceber que a memória disponível aumenta.

Depois de ver este código rodando, você deve estar se perguntando: “como eu sei quando o garbage collector vai ser executado?”. Não é possível saber. O controle da execução do garbage collector é da JVM. Quando a JVM decidir que é hora de executá-lo, ele será executado. Note que executar o garbage collector toda hora não seria recomendável, já que ele ocupa recursos computacionais.

Outro ponto importante a respeito do garbage collector é que, como ele é controlado pela JVM, não é possível forçar a sua execução via programação. O máximo que pode ser feito é a chamada do método System.gc() (ou Runtime.getRuntime().gc()). Este método notifica a JVM que a aplicação gostaria que o garbage collector fosse executado, mas não garante que ele realmente será executado no momento desejado.

O método finalize
A classe Object do Java possui um método chamado finalize(), que pode ser sobrescrito pelas classes que herdam de Object (isto é, qualquer classe). Quando o garbage collector decide que determinado objeto será destruído por não ser mais referenciado, ele chama o método finalize() no objeto logo antes de destruí-lo.

Apesar do método finalize() ser uma chance que o programador tem para liberar recursos associados ao objeto no momento em que ele será destruído, sobrescrever o finalize() não é recomendado em nenhuma situação. O motivo é simples: como não existe garantia que o objeto será destruído, também não existe garantia que o finalize() será executado. A própria Sun não recomenda sobrescrever o método finalize(). A liberação de recursos pode ser feita de outras formas, como utilização de blocos try/catch/finally e/ou criação de métodos específicos para este fim (método close(), por exemplo).

Para mais informações sobre este tópico, consulte: http://java.sun.com/developer/TechTips/2000/tt0124.html.

Causando um memory leak em Java
Após o entendimento do que é um memory leak e como funciona o garbage collector do Java, vamos agora mostrar como causar um memory leak em Java e o que fazer para evitá-lo. Primeiramente, gostaria de reforçar que memory leaks são difíceis de descobrir (às vezes é preciso recorrer a ferramentas externas) e sempre são causados por erro de programação. Normalmente os programadores não se preocupam muito com eles, até o momento em que começam a consumir uma quantidade excessiva de memória ou até derrubar a JVM (quando a memória acaba, a JVM lança um java.lang.OutOfMemoryError e termina).

Comentei na seção 3 que o garbage collector é capaz de detectar objetos não-referenciados e destruí-los, liberando a memória. Para criar um memory leak basta manter a referência a um ou mais objetos no código, mesmo sem utilizá-la depois. Dessa forma o garbage collector nunca poderá destruir os objetos, e eles continuarão existindo na memória mesmo não sendo mais acessíveis. Observe este exemplo simples de implementação de uma pilha:

public class Pilha {
private List pilha = new ArrayList();
int count = 0;
public void push(Object obj) {
pilha.add(count++, obj);
}
public Object pop() {
if(count == 0) {
return null;
}
return pilha.get(–count);
}
}

Cada vez que um elemento é colocado ou removido da pilha, um contador controla a posição do último elemento. Este é um caso visível de memory leak. A pilha tem referências cadastradas para todos os objetos contidos nela. No entanto, por mais que os objetos sejam todos removidos da pilha, a pilha continuará referenciando os objetos removidos, o que impossibilitará o gargabe collector de recuperar esta memória.

Para resolver a situação nesse caso, basta eliminar a referência ao objeto quando ele for removido da pilha:

public class Pilha {
private List pilha = new ArrayList();
int count = 0;
public void push(Object obj) {
pilha.add(count++, obj);
}
public Object pop() {
if(count == 0) {
return null;
}
Object obj = pilha.get(–count);
pilha.set(count, null);
return obj;
}
}

Atribuir a referência do objeto para null fará com que a pilha não mais referencie o objeto, possibilitando ao garbage collector a destruição do mesmo.

Este exemplo tem por objetivo mostrar como memory leak em Java é possível. É difícil alguém implementar uma pilha desta forma (ainda mais que Java já possui uma classe Stack para esta finalidade). De qualquer forma, imagine uma situação semelhante a essa onde milhares ou até milhões de objetos fiquem inacessíveis e ainda assim referenciados. Numa aplicação rodando sem parar num servidor de aplicação, por exemplo, isso pode acarretar o término da JVM por falta de memória após alguns dias de memory leaks acumulados. Numa situação como essa, encontrar o erro pode ser uma tarefa extremamente complicada e trabalhosa.
Recomendações para evitar memory leaks

Acredite: seguir algumas recomendações para evitar os memory leaks é muito mais fácil do que detectá-los após o código ter sido finalizado. Como o garbage collector facilita bastante o trabalho do programador, basta prestar atenção em alguns pontos principais que são causas comuns de memory leaks:
* Cuidado com coleções de objetos (arrays, listas, maps, vectors, etc.). Às vezes elas podem guardar referências de objetos que não são mais necessários.
* Ainda relacionado às coleções de objetos, se as mesmas forem static ou durarem todo o tempo de vida da aplicação, o cuidado deve ser redobrado.
* Ao programar situações onde seja necessário registrar objetos como event listeners, tome o cuidado de remover os registros desses objetos caso não sejam mais necessários. Resumindo: elimine todas as referências a objetos desnecessários. Fazendo isso, o garbage collector terá condições de fazer o seu trabalho completamente e você estará livre dos memory leaks em suas aplicações.

Este artigo procurou demonstrar que memory leaks existem em Java, ao contrário do que muitas pessoas pensam. Foi mostrado como criar uma situação de memory leak e como cuidar para que situações desse tipo sejam evitadas, a fim de não prejudicarem as aplicações.

==========
Fonte:

Ranking da pobreza

– Sair do refeitório com palito na boca (200 pts)
– Dormir depois do almoço debruçado na mesa (400 pts)
– Chamar sua sala de meu escritório (250 pts)
– Levar fruta do almoço para o setor (100 pts)
– Ter armário (99 pts)
– Botar foto de artistas no armário (300 pts)
– Sair da empresa com crachá pendurado (350 pts)
– Chamar empresa de firma (450 pts)
– Achar que o sindicato é seu aliado (100 pts)
– Ficar mascando palito de dente a tarde toda (280 pts)
– Pedir cigarro para os colegas (150 pts)
– Vender os Tickets e VT’s (320 pts)
– Andar com celular pendurado na cintura (500 pts)
– Colocar apelido nos colegas (250 pts)
– Molhar cabelo para ir embora (400 pts)
– Ter o “pentezinho” marrom (350 pts)
– Dizer para família que trabalha com computador (400 pts)
– Esperar o dia do pagamento pra sair pra balada (600 pts)
– Usar molho de chave pendurado na cintura (300 pts)
– Fazer um vulcão de arroz e encher de feijão no meio (550pts)
– Usar a unha do mindinho comprida (10.300 pts)
– Colocar a gravata só quando chega ao escritório (330 pts)
– Tirar a gravata pra sair pra almoçar (550 pts)
– Usar cortador de unhas no chaveiro (300 pts)
– Comer acima de 500 gramas no almoço (400 pts)
– Tomar uma pinguinha antes do almoço pra abrir o apetite (400pts)
– Ir trabalhar com camisa de time (1.500 pts)

Confira sua pontuação:
– 0 a 99 pts – Chefe
– 100 a 299 pts – Nem chefe e nem peão
– 300 a 599 pts – Aprendiz de Peão
– 600 a 1199 pts – Peão Junior
– 1200 a 1999 pts – Peão Senior
– Acima de 2000 pts – Peão Master!!