草庐IT

垃圾分类

全部标签

java - 垃圾回收实现

java的垃圾回收算法是用什么语言实现的,我想是c,请确认一下? 最佳答案 这取决于JVM。通常,垃圾收集器是用与JVM相同的语言实现的,但情况并非总是如此。在Maxine中,JVM和垃圾收集器都是用Java实现的。在Jikes中,JVM和垃圾收集器都是用Java实现的。在Rava中,JVM是用Ruby实现的,垃圾收集器根本没有实现:Ruby已经是一种内存管理语言,不需要实现单独的垃圾收集器。在IKVM中,JVM是用C#和CIL实现的,垃圾收集器根本没有实现:CLIVES已经是一个内存管理的环境,不需要再实现一个独立的垃圾收集器。在

java - Java 的垃圾收集器会继续处理循环内声明的变量吗?

如果我有:for(inti;i!=100;i++){ArrayListmyList=buildList();//...moreworkhere}我是否必须在循环结束时将myList设置为null以使GC回收它用于myList的内存? 最佳答案 GC会自动清理所有不再在范围内的变量。在block内声明的变量,例如for循环,将只在该block内的范围内。一旦代码退出block,GC将删除它。一旦循环迭代结束,就会发生这种情况,因此一旦循环的每次迭代结束,列表就符合垃圾回收条件。变量的范围也是i在您的示例循环后无效的原因。请注意,只有在

java - 垃圾收集从 Java 1.4 到 Java 6 的变化?

我们最近将我们的一个应用程序从Java1.4升级到了Java6。通过一些负载和性能测试,我们观察到Java6中的可用内存总体上保持在比Java1.4过去低得多的水平。在使用Java6对应用程序进行一些分析后,我们注意到许多不再被任何其他对象引用的对象(即垃圾收集的候选者)保​​留在内存中,并且显然从未被垃圾收集。我们将其视为可用内存不足的原因。问题是:从Java1.4到Java6,垃圾回收的行为方式是否发生了变化? 最佳答案 didthewaygarbagecollectionbehaveschangedfromJava1.4toJ

Java HotSpot 1.6 VM,垃圾收集——可怕的 PermGen

我的应用程序显示“OldGeneration”/“TenuredGeneration”大小不断增加,当这达到“OldGen”的最大限制时,PermGen大小突然增加。这是我的代数:-Xmx1200m-Xms1200m-Xmn450m-XX:MaxPermSize=600m-XX:+UseParallelGC这是在32位Fedora上,所以不能有比这更大的堆。虽然该应用程序使用了SpringIOC和Hibernate,但它没有进行任何花哨的类加载,SpringApp-context.xml定义了大约1000个Bean。此应用从175MB的PermGen开始,在几个小时内稳步增加到约250

java - Java 7 与 Java 6 的年轻垃圾收集暂停时间更长

我注意到使用java7的每个年轻垃圾收集平均比使用java6多10毫秒。我使用的是1.6.0_31和1.7.0_21。配置没有改变,硬件也没有改变,JVM参数是:-server-XX:+DisableExplicitGC-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+TieredCompilation-XX:+AggressiveOpts-Xms1g-Xmx1g-XX:MaxNewSize=256m-XX:NewSize=256mJava7:S0CS1CS0US1UECEUOCOUPCPUYGCYGCTFGCFGCTGCT26176.026176

java - Java 中的零垃圾大字符串反序列化,Humongous 对象问题

我正在寻找一种从Java中的byte[]反序列化String的方法,同时尽可能少地产生垃圾。因为我正在创建自己的序列化器和反序列化器,所以我可以完全自由地在服务器端(即序列化数据时)和客户端(即反序列化数据时)实现任何解决方案。我通过遍历String的字符(String.charAt(i))并将每个char(16位值)转换为2x8位值。关于这个here有一个很好的辩论.另一种方法是使用反射直接访问String的底层char[],但这超出了问题的范围。但是,我似乎不可能在不创建char[]两次的情况下反序列化byte[],这看起来,好吧,奇怪。程序:创建char[]遍历byte[]并填充

java - G1 垃圾收集器 : Why survivor space is always full?

这是jmap-heap命令的输出:SurvivorSpace:regions=52capacity=54525952(52.0MB)used=54525952(52.0MB)free=0(0.0MB)100.0%used我已经执行了很多次,我发现capacity的值总是等于used。我的问题是为什么幸存者空间总是满的(而且这么小)?我指定了-Xmx2200m-Xms2200m-Xmn1100m。(我预计survivorspace应该是220M,也就是说survivorregion应该有更多的空间)--更新--jheap的完整输出:Garbage-First(G1)GCwith2thre

java - 多标签文档分类

我有一个数据库,我在其中存储基于以下三个字段的数据:id、text、{labels}。请注意,每个文本都已分配给多个标签\标签\类。我想建立一个模型(weka\rapidminer\mahout),它能够推荐\将一堆标签\标签\类分类到给定的文本。我听说过SVM和朴素贝叶斯分类器,但不确定它们是否支持多标签分类。任何引导我走向正确方向的东西都非常受欢迎! 最佳答案 基本的多标签分类方法是one-vs.-the-rest(OvR),也称为二进制相关性(BR)。基本思想是您采用现成的二元分类器,例如朴素贝叶斯或支持vector机,然后创

对话框中的java垃圾收集

*我现在遇到一个很奇怪的javaGC问题,当我试图在JFrame中制作一个按钮,当我点击按钮时,它显示一个JDialog,需要处理和显示一些图像,需要将近200M内存。但问题是当我关闭对话框并重新打开它时,有时它会导致java.lang.OutOfMemoryError。(不是每次)为了解决这个问题,我简化了这个问题并做了一些实验,这让我更加困惑。我在“实验”中使用的代码如下所示。当我点击一个框架中的按钮时,我为一个整数数组分配了160M内存,并显示了一个对话框,但是如果我关闭对话框并重新打开它,就会出现OutOfMemoryError。我调整了代码和结果是:如果我不创建对话框并显示它

java - 垃圾收集中疏散和压缩之间的根本区别是什么?

我阅读了大量有关JavaSE6和7的HotSpotGC的文档。在讨论获取连续空闲内存区域的策略时,提出了两种“竞争”方法:Evacuation(通常应用于年轻一代),其中Activity对象从'from'复制到空的'to'和Compaction(CMS的后备),其中Activity对象被移动到碎片区域内的一侧以形成连续的block使用未使用的内存。这两种方法都与“Activity集”的大小成正比。不同之处在于疏散需要比现场集x2倍的空间,而压实则不需要。为什么我们根本需要Evacuation技术?需要完成的复制量是相同的,但是它需要保留更多的堆大小,并且不允许更快的重新映射的引用资料。