生产环境jvm内存运行1小时,就接近xmx,系统奇慢。大量的jasperreport无法释放。

附java bug地址
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6525563

恩 是的，你的这个问题我在09年的时候也遇到过的，dump文件查看里面的根节点所有都是数据，相当的惨呀，当时我们用的是杰表打印，然后杰表里面的很多样式标签不是引用，还有就是用户数据太多最后导致内存溢出导致崩溃。

其实有时间和是否关闭了流没有关系，也可能是你的用户点一个报表，点一次没有出来，继续点第二次，还是没出来，然后就狂点，最后。。。。

这个不可能.1.我们用的是applet，点击打印后button的状态是disabled，报表打印完成后才是enabled.
           2.我们有日志，可以跟踪每次打印，看打印次数不能非常的多。

看到了一段代码正在研究，可能有问题，需要oss.reset();


ObjectStreamClass类代码有如下cache内部类。

    private static class Caches {
	/** cache mapping local classes -> descriptors */
	static final ConcurrentMap<WeakClassKey,Reference<?>> localDescs =
	    new ConcurrentHashMap<WeakClassKey,Reference<?>>();

	/** cache mapping field group/local desc pairs -> field reflectors */
	static final ConcurrentMap<FieldReflectorKey,Reference<?>> reflectors =
	    new ConcurrentHashMap<FieldReflectorKey,Reference<?>>();

	/** queue for WeakReferences to local classes */
	private static final ReferenceQueue<Class<?>> localDescsQueue = 
	    new ReferenceQueue<Class<?>>();
	/** queue for WeakReferences to field reflectors keys */
	private static final ReferenceQueue<Class<?>> reflectorsQueue = 
	    new ReferenceQueue<Class<?>>();
    }	

  static ObjectStreamClass lookup(Class cl, boolean all) {
	if (!(all || Serializable.class.isAssignableFrom(cl))) {
	    return null;
	}
	processQueue(Caches.localDescsQueue, Caches.localDescs);
	WeakClassKey key = new WeakClassKey(cl, Caches.localDescsQueue);
	Reference<?> ref = Caches.localDescs.get(key);
	Object entry = null;
	if (ref != null) {
	    entry = ref.get();
	}
	EntryFuture future = null;
	if (entry == null) {
	    EntryFuture newEntry = new EntryFuture();
	    Reference<?> newRef = new SoftReference<EntryFuture>(newEntry);
	    do {
		if (ref != null) {
		    Caches.localDescs.remove(key, ref);
		}
		ref = Caches.localDescs.putIfAbsent(key, newRef);
		if (ref != null) {
		    entry = ref.get();
		}
	    } while (ref != null && entry == null);
	    if (entry == null) {
		future = newEntry;
	    }
	}
	
	if (entry instanceof ObjectStreamClass) {  // check common case first
	    return (ObjectStreamClass) entry;
	}
	if (entry instanceof EntryFuture) {
	    future = (EntryFuture) entry;
	    if (future.getOwner() == Thread.currentThread()) {
		/*
		 * Handle nested call situation described by 4803747: waiting
		 * for future value to be set by a lookup() call further up the
		 * stack will result in deadlock, so calculate and set the
		 * future value here instead.
		 */
		entry = null;
	    } else {
		entry = future.get();
	    }
	}
	if (entry == null) {
	    try {
		entry = new ObjectStreamClass(cl);
	    } catch (Throwable th) {
		entry = th;
	    }
	    if (future.set(entry)) {
		Caches.localDescs.put(key, new SoftReference<Object>(entry));
	    } else {
		// nested lookup call already set future
		entry = future.get();
	    }
	}
	
	if (entry instanceof ObjectStreamClass) {
	    return (ObjectStreamClass) entry;
	} else if (entry instanceof RuntimeException) {
	    throw (RuntimeException) entry;
	} else if (entry instanceof Error) {
	    throw (Error) entry;
	} else {
	    throw new InternalError("unexpected entry: " + entry);
	}
    }

   下一步用jmeter压一下，再看heap情况。

用jmeter压过后，jvm表现得非常好。200个并发，循环500次，cpu在20%，内存在740m，1.3g左右，有些上涨但一会就下来了。看来不是jasperreport的问题，那到底是什么问题呢。最后实在没有办法，查看打印日志，每个打印都重做一遍。在做到一个打印时出现问题，点击打印后按钮不动，用visual vm查看堆内存一直在向上，再点一下jvm瞬间到达4g，jvm满了但gc不起作用。同样的报表，不一样的数据，会有这样的问题。明天再分析，争取给个结论。

终于结束了，找到了问题。jasperreport3.7.0没有提供setLeftMargin()和setRightMargin方法，自己写了程序通过反射写JasperReport两个属性，由于一点小的疏忽，x轴正常允许操作人员调整1到40，但实际上设计报表时，只允许到30，照成x轴越界，调用fillReport方法时，jasperreport无法判断报表打印界限，无限的生成JRBasePrintPage对象，存放到JasperPrint的pages属性中(ArrayList)，直到jvm内存耗尽。一个小的低级失误，造成了大错。

我也想分析，不过dump文件不知道如何分析啊，哪里有教程可否共享

MAT、JProfiler、IBM HeapAnalyzer，都可以的，如果简单用的话不难。

如果早用jprofile查看一下占用内存的是哪些对象也许很快就搞定了

什么需求让你需要设置这两个东西，难道没用使用ireport吗