*从数据库中提取CLOB类型字段的内容并转换为字符串
*@paramrs数据库ResultSet,含有CLOB类型的字段
*@paramclobidx含有CLOB类型字段在ResultSet中的索引
*@returnȡ出的字符内容
*@throwsSQLException
*/
publicstaticStringBuffergetCLOBContent(ResultSetrs,intclobidx)throwsSQLException
{
log.debug("开始获取CLOB内容,index=" clobidx)
Oracle.sql.CLOBclobField=((OracleResultSet)rs).getCLOB(clobidx)
longclen=clobField.length()
charclobArray[]=newchar[(int)clen]
intreadednum=clobField.getChars(1,(int)clen,clobArray)
StringBuffersb=newStringBuffer()
sb.append(clobArray)
log.debug("读出的CLOB内容为[\r\n" sb.toString() "]")
returnsb
}
java是传引用，所以大不大无所谓只是并发的时候如果你又需要对对象做修改，那就要注意对性能影响可能很大了，这个影响是因为你需要锁住对象确保线程安全，浪费了cpu资源，而不是因为对象大这个原因，也就是说如果你对象虽然大，但是你线程不会对它进行修改，那性能还是很高的
jvm默认多大的对象是大对象？对象的内存分配——对象优先在Eden分配当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
testAllocation()方法中，尝试分配3个2MB大小和1个4MB大小的对象，在运行时通过-Xms20M、-Xmx20M、-Xmn10M这3个参数限制了Java堆大小为20MB，不可扩展，其中10MB分配给新生代，剩下的10MB分配给老年代。-XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的空间比例是8:1，从输出的结果也可以清晰地看到“eden space 8192K、from space 1024K、to space 1024K”的信息，新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量）。执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC，这次GC的结果是新生代6651KB变为162KB，而总内存占用量则几乎没有减少（因为allocation1、allocation2、allocation3三个对象都是存活的，虚拟机几乎没有找到可回收的对象）。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间已不足以分配allocation4所需的4MB内存，因此发生Minor GC。GC期间虚拟机又发现已有的3个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小），所以只好通过分配担保机制提前转移到老年代去。这次GC结束后，4MB的allocation4对象顺利分配在Eden中，因此程序执行完的结果是Eden占用4MB（被allocation4占用），Survivor空闲，老年代被占用6MB（被allocation1、allocation2、allocation3占用）。
下面看看使用Parallel Scavenge收集器的情况：
没有发生新生代GC，直接把allocation4分配到老年代上。
对象的内存分配——大对象直接进入老年代——典型的大对象
很长的字符串以及数组
对象的内存分配——大对象直接进入老年代——大对象噩梦
比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。
对象的内存分配——大对象直接进入老年代——原因
大于-XX:PretenureSizeThreshold设置值的对象直接在老年代分配。这样做的目的是避免在Eden区及两个Survivor区之间发生大量的内存复制。
PretenureSizeThreshold被设置为3MB（就是3145728，这个参数不能像-Xmx之类的参数一样直接写3MB），因此超过3MB的对象都会直接在老年代进行分配。
PretenureSizeThreshold参数只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，Parallel Scavenge收集器一般并不需要设置。
