Usamos cookies para medir audiência e melhorar sua experiência. Você pode aceitar ou recusar a qualquer momento. Veja sobre o iMasters.
hum, interessante. Acho que a diferença na memória pode ser também pelo fato do Scanner não fazer tanta regex pesada quanto o BufferedReader, que às vezes é mal utilizado com buffering demais.
No meu sistema de entrada de dados, percebo que Scanner com try with resources resolve bem, e a experiência do usuário melhora pq evita travamentos. Acho que é um caso de testar na real, pq teoria às vezes não captura o que rola na prática, especialmente com JVM e garbage collector.
Se o time tivesse que medir uma coisa aqui, seria performance ou documentação?
Já passei por isso, o Scanner às vezes parece mais leve mesmo sendo mais pesado teoricamente. Acho que o uso do try with resources ajuda na gestão do recurso, mas o impacto real na memória depende do contexto. No meu time, a gente prefere usar o Scanner pra problemas rápidos que precisam de leitura de entrada simples.
Isso é bem comum na prática, pq a teoria às vezes não bate com o que rola na JVM. O Scanner dentro do try with resources garante que o GC possa liberar o recurso mais cedo, mesmo que seja mais pesado na teoria.
Boa, mas será que essa questão de memória também impacta na performance geral?