Java: Diferenças entre as classes String, StringBuffer e StringBuilder

String

A classe String com certeza é uma das principais classes da linguagem Java, esta classe é responsável pelo armazenamento de dados do tipo texto, as principais características da classe String são:

  • Seu nome completo é java.lang.String;
  • É um objeto imutável, ou seja, depois que criado seu conteúdo jamais é alterado;
  • É uma classe final, ou seja, não pode ser herdada por nenhuma outra classe.

Um objeto imutável quando criado na memória nunca terá seu valor alterado, no exemplo iremos demonstrar esta situação:

  1. É criado uma string com o conteudo “oficina da”;
  2. É criado uma string com o conteudo “net”;
  3. É criado uma nova string com o conteudo “oficina da net”;
  4.  As strings “oficina da ” e “net” estão sem referência,
            * ou seja, estão disponiveis para o gargage collector.

    As strings “oficina da ” e “net” estão sem referência, ou seja, estão disponíveis para o gargage collector.

StringBuffer

A classe StringBuffer é geralmente utilizada quando precisamos armazenar um grande número de caracteres, as principais características da classe StringBuffer são:

  • Seu nome completo é java.lang.StringBuffer;
  • É um objeto mutável, ou seja, o seu valor pode ser alterado, isso significa que o valor armazenado em sua instância pode ser alterado;
  • É uma classe final, não pode ser herdada por nenhuma outra classe;
  • Todos os seus métodos são synchronized, assim é uma classe preparada para um ambiente onde se utiliza os recursos de muilti-thread.

Exemplo da utilização da classe StringBuffer:

  1. É armazenado uma String com o valor “oficina”, através da chamada do método append;
  2. É concatenado o valor de “da “, agora temos na StringBuffer o valor de”oficina da “;
  3. É concatenado a variável nome o valor de “net”,  agora temos na StringBuffer o valor de “oficina da net”.

StringBuilder

A classe StringBuilder é similar a classe StringBuffer, a única diferença é que os seus métodos não são synchronized.
Esta classe é indicada quando não é necessário ter o controle sobre as thread que irão modificar o conteúdo da instância, por isso esta classe é mais utilizada do que a classe StringBuffer.
Exemplo da utilização da classe StringBuilder:

  1. É armazenado na instância de nome o valor de “oficina”, através da chamada do método append;
  2. É concatenado a variável nome o valor de “da “, agora temos na StringBuilder o valor de “oficina da “;
  3. É concatenado a variável nome o valor de “net”, agora temos na StringBuilder o valor de “oficina da net”.

Com isso podemos concluir que a concatenação de um StringBuilder comparado com a String é muito mais rápida, isto porque um objeto String é imutável, e o StringBuilder é um objeto mutável.

Vale lembrar que a unica diferença entre StringBuffer e a StringBuilder,  é que todos os métodos da StringBuffer são synchronized, enquando os da StringBuilder não são.

Texto encontrado no site oficinadanet.com.br


Diferença entre comandos DDL, DML, DCL e TCL

DDL – Data Definition Language ( DDL) são usadas para definir a estrutura de banco de dados ou esquema. Alguns exemplos:

CREATE- para criar objetos no banco de dados
ALTER – altera a estrutura da base de dados
TRUNCATE – remover todos os registros de uma tabela, incluindo todos os espaços alocados para os registros são removidos
COMMENT – adicionar comentários ao dicionário de dados
RENAME – para renomear um objeto

DML – Data Manipulation Language ( DML) são utilizados para o gerenciamento de dados dentro de objetos do banco. Alguns exemplos:

SELECT- recuperar dados do banco de dados
INSERT – inserir dados em uma tabela
UPDATE – atualiza os dados existentes em uma tabela
DELETE – exclui registros de uma tabela,
CALL – chamar um subprograma PL / SQL
EXPLAIN PLAN – explicar o caminho de acesso aos dados
LOCK TABLE – controle de concorrência

DCL – Data Control Language ( DCL ) declarações. Alguns exemplos:

GRANT – atribui privilégios de acesso do usuário a objetos do banco de dados
REVOKE – remove os privilégios de acesso aos objetos obtidos com o comando GRANT

TCL – Transaction Control Language – (Controle de Transações) são usados ​​para gerenciar as mudanças feitas por instruções DML . Ele permite que as declarações a serem agrupadas em transações lógicas .

COMMIT – salvar o trabalho feito
SAVEPOINT – identificar um ponto em uma transação para que mais tarde você pode efetuar um ROLLBACK
ROLLBACK – restaurar banco de dados ao original desde o último COMMIT


Apache Tomcat resolvendo problemas de “OutOfMemoryError e PermGen”

Para solucionar estes problemas do Tomcat, a solução é revisar a configuração de memória necessária para sua aplicação e aumentar a disponibilidade de memória alocada no Tomcat. Para reconfigurar a memória do Tomcat, é necessário editar os arquivos catalina.bat(Windows) ou catalina.sh(Linux)  ou então utilizar o gerenciador do tomcat (aquele que fica na pasta \bin e geralmente termina em w.exe – exemplo: tomcatw.exe).

Caso você opte por utilizar os arquivos Catalina será necessário adicionar a seguinte configuração:

–JvmMx 1024
Isso define o heap máximo disponível para o Tomcat em 1Gb de memória:

Entendendo HeapSpace:

O Heap Space é uma espécie de Memória dinâmica onde o Java armazena suas variáveis e instâncias de objetos. Este espaço de memória pode aumentar ou diminuir ao longo do tempo, dinamicamente, de acordo com a quantidade de objetos usados no programa.

Quantidade inicial de memória dinâmica: O Xms define a quantidade inicial de memória dinâmica alocada no início da JVM.
Quantidade máxima de memória dinâmica: O parâmetro Xmx define a quantidade máxima de memória dinâmica que a Máquina Virtual Java pode alocar para armazenar esses objetos e variáveis.

O famoso PermGen Space
O PermGen Space é parte da memória chamada de estática ou permanente e é utilizada para carregar suas classes (arquivos .class), internalizar Strings (string pool), entre outras coisas no seu projeto.

Quantidade inicial de memória permanente: O parâmetro XX:MaxPermSize define a quantidade máxima de memória permanente que a JVM pode utilizar
Quantidade máxima de memória permanente: O parâmetro XX:PermSize define o tamanho inicial alocado para sua aplicação.

Exemplo:
-XX:MaxPermSize=512m
Esta configuração (-XX:MaxPermSize=512m) define que memória permanente do tomcat tenha no máximo 512Mb de memória.

Como alterar as configurações de memória do Tomcat nos sistemas operacionais:

No Windows:

Para alterar as configurações de memória do Tomcat é obrigado a usar a ferramenta de linha de comando do tomcat6.

O comando altera as configurações de heap space e permgen:

tomcat6 //US//Tomcat6 –JvmMx 1024 ++JvmOptions=”-XX:MaxPermSize=256m”

Este comando deve ser executado a partir do diretório C:/Program Files/Apache Software Foundation/Tomcat 6.0/bin ou de onde o Tomcat tiver instalado.
Na imagem abaixo, podemos verificar a alteraçã ofeita na execução do comando

configuracaoTomcat

No Linux:

Para alterar as configurações de memória do Tomcat é necessário acessar via SSH a ferramenta de linha de comando do linux.
O seguinte arquivo catalina.sh, se a instalação foi executa com padrão esse arquivo se encontra no seguinte local.

/usr/Java/apache-tomcat-6.0.18/bin/catalina.sh

imagem1
Alterar ou incluir a seguinte linha.

export JAVA_OPTS=”-server -Xms768m -Xmx1024m -XX:MaxPermSize=256m”

imagem2

Após alteração salvar e resetar o Tomcat.

Dica rápida:

Caso esse problema esteja acontecendo dentro de um tomcat interno do Eclipse coloque no Vm Arguments (onde 512, 768 e 256 ficam como opcionais de configuração)

-Xms512M -Xmx768M -XX:PermSize=256M

vm-arguments

Heap space
SEVERE: Servlet.service() for servlet jsp threw exception java.lang.OutOfMemoryError: Java heap space
PermGen
MemoryError: PermGen space java.lang.OutOfMemoryError: PermGen space


Compilando todos os objetos inválidos do Oracle

O Comando a seguir força o banco a compilar todos os objetos inválidos de um determinado usuário.(Substitua pelo usuário do banco)

exec dbms_utility.compile_schema(SCHEMA => <USUARIO>);

Para descobrir os objetos inválidos do banco, utilize:

select object_name from all_objects where status = 'INVALID'

Java, Resolvendo ORA-01000: maximum open cursors exceeded

Achei este texto muito interessante no http://blog.michaelnascimento.com.br. As querys ajudam a debugar sistemas onde ocorrem o famoso ORA-01000 causado por Connections, Statements e ResultSets deixados abertos. Normalmente temos algo como:

Connection con = //obtem conexao;
PreparedStatement ps = con.prepareStatement("SELECT ...");
ResultSet rs = ps.executeQuery();

while (rs.next()) {
   // ...
}

rs.close();
ps.close();
con.close();

texto na integra: Note que eu estou sendo otimista, supondo quePreparedStatements sejam usados ao invés de concatenarStrings para executar consultas e que o método close() nas três instâncias esteja pelo menos no código. Se você não fez nem isso, corra atrás. :-) O bug é que, quando ocorre uma exceção, durante o processamento do select, nenhum dos três objetos é fechado. Então, a primeira solução é colocar o fechamento num bloco try/finally, como mostrado abaixo:

Connection con = null;
PreparedStatement ps = null;
ResultSet rs =null;

try {
   con = //obtem conexao;
   ps = con.prepareStatement("SELECT ...");
   rs = ps.executeQuery();

   while (rs.next()) {
      // ...
   }
} finally {
   if (rs != null) {
      rs.close();
   }

   if (ps != null) {
      ps.close();
   }

   if (con != null) {
      con.close();
   }
}

Tudo certo, né? Errado. Se ocorrer uma exceção ao fechar rsps econ nunca serão fechados. Então a melhor solução seria:

Connection con = null;
PreparedStatement ps = null;
ResultSet rs =null;

try {
   con = //obtem conexao;
   ps = con.prepareStatement("SELECT ...");
   rs = ps.executeQuery();

   while (rs.next()) {
      // ...
   }
} finally {
   if (rs != null) {
      try {
          rs.close();
      } catch (SQLException sqe) {
          // logar excecao
      } catch (RuntimeException re) {
          // logar excecao
      }
   }

   if (ps != null) {
      try {
          ps.close();
      } catch (SQLException sqe) {
          // logar excecao
      } catch (RuntimeException re) {
          // logar excecao
      }
   }

   if (con != null) {
      try {
          con.close();
      } catch (SQLException sqe) {
          // logar excecao
      } catch (RuntimeException re) {
          // logar excecao
      }
   }
}

Ok, você vai me dizer, muito legal isso. Mas meu projeto tem milhares de classes e eu não sei onde eu esqueci de fazer isso. Ou, ainda, eu uso um framework O/RM ou JDBC que deveria resolver este problema pra mim. Bem, nesse caso, você tem como descobrir qual a instrução SQL do(s) cursor(es) que está(ão) abertos. Primeiro, você precisa do SID das sessões abertas pela sua aplicação, que você pode obter assim:

select o.sid, osuser, machine,
count(*) num_curs
from v$open_cursor o, v$session s
where o.sid=s.sid
group by o.sid, osuser, machine
order by num_curs;

Se estiver usando connection pool e um máquina só, pode-se usar estes dados para filtrar os resultados:

select o.sid, osuser, machine,
count(*) num_curs
from v$open_cursor o, v$session s
where o.sid=s.sid and
user_name = 'USUARIO_BANCO' and
machine = 'NOME_MAQUINA_APLICACAO'
group by o.sid, osuser, machine
order by  o.sid;

Utilize os SIDs na seguinte query:

select q.sql_text, count(*)
from v$open_cursor o, v$sql q
where q.hash_value=o.hash_value and o.sid IN (<SIDs>)
group by q.sql_text
order by 2;

Se o framework ou servidor de aplicações que você utiliza faz cache de statements (Hibernate e JBoss fazem, por default), é normal que exista um certo número de cursores com o mesmo SQL em aberto. Suspeite daquelas instruções que tenham um número de cursores muito maior que as outras e investigue de onde elas vêm. E se sua aplicação usa PL/SQL, saiba que as instruções contidas nas suas procedures/functions são contadas individualmente como cursores. Espero ter ajudado 😉


Páginas:1234567...17