The difference between HashMap and Hashtable

import java.util.ArrayList; import java.util.Hashtable; import java.util.Iterator; import java.util.Map; /** * Created by yanggf on 2017/12/28. */ public class FastFailTest { public static ArrayList<Integer> list = new ArrayList<>(); public static class ThreadOne extends Thread{ public void run() { Iterator<Integer> iterator = list.iterator(); while (iterator.hasNext()){ int i = iterator.next(); System.out.println(“ThreadOne find” + i); try { Thread.sleep(10); }…

java 读取配置文件

public class ApplicationProperty { private final Properties prop = new Properties(); private static ApplicationProperty instance = null; private ApplicationProperty(){} public static synchronized ApplicationProperty getInstance(){ if (instance == null){ instance = new ApplicationProperty(); return instance; } else { return instance; } } public Properties getProperty(){ try { InputStream in = this.getClass().getClassLoader().getResourceAsStream(“application.properties”); // System.out.println(in.toString()); this.prop.load(in); in.close(); }…

java.lang.OutOfMemoryError:GC overhead limit exceeded填坑心得

  http://www.cnblogs.com/hucn/p/3572384.html 我遇到这样的问题,本地部署时抛出异常java.lang.OutOfMemoryError:GC overhead limit exceeded导致服务起不来,查看日志发现加载了太多资源到内存,本地的性能也不好,gc时间消耗的较多。解决这种问题两种方法是,增加参数,-XX:-UseGCOverheadLimit,关闭这个特性,同时增加heap大小,-Xmx1024m。坑填了,but why? OOM大家都知道,就是JVM内存溢出了,那GC overhead limit exceed呢? GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略,通过统计GC时间来预测是否要OOM了,提前抛出异常,防止OOM发生。Sun 官方对此的定义是:“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是,超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“ 听起来没啥用…预测OOM有啥用?起初开来这玩意只能用来Catch住释放内存资源,避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用,但是可以在应用挂掉之前做最后的挣扎,比如数据保存或者保存现场(Heap Dump)。 而且有些时候这个策略还会带来问题,比如加载某个大的内存数据时频繁OOM。 假如你也生产环境中遇到了这个问题,在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC,最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用,old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError,这样OOM时会自动做Heap Dump,可以拿MAT来排查了。还要留意young区,如果有过多短暂对象分配,可能也会抛这个异常。 日志的信息不难理解,就是每次gc时打条日志,记录GC的类型,前后大小和时间。举个例子。 33.125: [GC [DefNew: 16000K->16000K(16192K), 0.0000574 secs][Tenured: 2973K->2704K(16384K), 0.1012650 secs] 18973K->2704K(32576K), 0.1015066 secs] 100.667:[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] GC和Full GC代表gc的停顿类型,Full GC代表stop-the-world。箭头两边是gc前后的区空间大小,分别是young区、tenured区和perm区,括号里是该区的总大小。冒号前面是gc发生的时间,单位是秒,从jvm启动开始计算。DefNew代表Serial收集器,为Default New Generation的缩写,类似的还有PSYoungGen,代表Parallel Scavenge收集器。这样可以通过分析日志找到导致GC overhead limit exceeded的原因,通过调节相应的参数解决问题。 文中涉及到的名词解释, Eden Space:堆内存池,大多数对象在这里分配内存空间。 Survivor…

Gson jsonString Map object transfer

//transfer jsonstring into  map private String jsonstrToMap() {     Gson gson2 = new GsonBuilder().enableComplexMapKeySerialization().create();     Map<String, String> map = new HashMap<String, String>();     map.put(“key1”, “value1”);     map.put(“key2”, “value2”);     map.put(“key3”, “value3”);     String jsonString = gson.toJson(map);     Type type = new TypeToken<Map<String, String>>() {}.getType();     Map<String, String> map2 = gson2.fromJson(jsonString, type);     String showString = “”;     for (String keyString : map2.keySet()) {         showString += keyString + “:” + map2.get(keyString) + “\n—–\n”;     }     showString += “———————-\n”;     return showString; } reference: http://blog.csdn.net/a249900679/article/details/51386660