java的内存泄露吗？？？

//可是对内存追踪，并没有清楚啊？？
这句话啥意思?
hehe,我不明白

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

Vector 里放的都是引用(指针),remove作用是把一个对象引用从Vector里删除,而不是把真正的对象从内存里清除,object = null;也只是把对象引用置成null.
真正的对象清除是由垃圾回收器自动回收的.
//可是对内存追踪，并没有清楚啊？？
就是用工具软件对内存里的内容进行查看(游戏工具里有很多这类的).
并不是你设置它为null它就马上清楚的
只有在垃圾收集的时候，没有被引用的对象会被收集掉
垃圾收集的时间是不确定的，跟Java虚拟机有关
你没有办法控制它
对，内存清除是不可能那么快的，我遇到过，原来用tomcat的时候。连续查询数据库8次左右，每次获取100条纪录，两次的时间间隔为2秒钟
结果Tomcat占用内存达到180M。过了5分钟，才完全恢复正常。
我在想是不是要把vector设为null。
可是我这个程序要一直用到它啊
引用为null，没有引用了，就可以被gc,至于什么时候清除，你没有编码强制执行，由VM认为合适的时候自己gc...
你设为null也没用啊，设为null又不是清除内存。
现代的高级JVM的GC是有原则的，以IBM JRE为例：当JVM仍然何以申请到内存时，从不进行GC，标注所有未被引用的对象（不可访问）；
当JVM申请内存得到OutOfMemoryError时，进行GC，清除所有“不可到达”的对象。注意：当JVM进行GC时，所有的响应全部停止，对于Web Application Server来说，就是不可访问。因此GC的时间需要尽可能缩小。比如说，开始就不去给JAVA指定过多的Heap Size，减少每次GC消耗的时间。System.gc()则是非常低效的语句，它将本来不需要GC的JVM启动GC过程。可以想象，如果你的程序中全都是这个System.gc()，效率将会有多糟糕？别忘了GC过程中，JVM停止一切非GC线程的！
小心你的数组
如果Java VM没有问题
内存泄漏通常和你的数组有关
楼上说的对，大概就这么请，需要的时候VM有自动的线程清，不过也不能认定System.gc()绝对低效，毕竟c++的程序员都是手动清楚的，如果你认为合适清楚的话，可以自己gc..
你发现用了太多变量，占用了太多内存的时候可以自己System.gc()嘛，，灵活些..
文件操作这一块会不会有问题,如果我要读一个文件赋给一个String 对象,而这个文件有200M, 会不会真的得要200M空间把所有文件内容放到内存中去才行呢?
如果我又把这个String 传给另一个或分解,这时候会不会又把空间加倍呢?
好象String对象没有这么大把。/
当然会有泄漏的情况发生。
不过如果用1.4的话，还是用ArrayList代替Vector吧，好处我就不多说了。
还有就是borland在出jb8的同时出了一个叫optimizert的产品，专门管理内存的，你可以试试
一种可能泄漏内存的模式
比如你自己做一个Stack对象，里面用数组来保持栈中引用
当你的元素出栈时，比如当前栈中有五个元素，你把第栈顶指针向下移动一个，但不将第5个元素清空，就导致无用的对象仍然存在有引用
我用一个StringBuffer读94M的日志文件就java.lang.OutOfMemoryError了.
这个是JVM分配多少内存，在哪个地方可以设置的(忘记...)
并不是你设置它为null它就马上清楚的
java连这点都解决不了，，如何能普遍推广呢?
只要对象不要太大好象就没什么问题吧,我用StringBuffer分段读,读一段后再用new StringBuffer()再造一个,看内存也很平稳,一直都保持在一个水平.读完了又回到了开始的水平.
而整个读的话,一直上升,到达内存的上限(我的是256M)后就出现OutOfMemoryError,然后程序完成,内存也迅速返回到初始的时候了.
都说了不能马上清除的，即使是硬编码System.gc(),也不能，清楚内存是后台的一个线程做的...
改成用c 编程序吧。java 太。
Java的内存有自己的回收机制好像不是一下子全部回收的，要慢慢的回收……
java的垃圾回收是在内存不够的时候才启动的，要想人工的话，采用System.gc()
http://expert.csdn.net/Expert/topic/1473/1473054.xml?temp=.1267511