精华内容
下载资源
问答
  • CPU高占用和并发操作HashMap的关系

    千次阅读 2017-08-31 23:17:11
    概述  本篇博客是描述生产环境出现的问题... 发现CPU占用为98%的情况后,当时,首先想的是到底是那个点,或者那块代码导致的这个问题啊,于是先查看了占用CPU的进程ID,查询进程ID后,再查看该进程下CPU占用较

    概述

             本篇博客是描述生产环境出现的问题,以及解决问题时的整个过程。

    场景

            生成环境出现CPU占用为98%的情况,当时那段时间也有相应的定时任务在运行。

    定位问题

            发现CPU占用为98%的情况后,当时,首先想的是到底是那个点,或者那块代码导致的这个问题啊,于是先查看了占用CPU较高的进程ID,查询进程ID后,再查看该进程下CPU占用较高的线程ID,然后,打印出相应线程的堆栈信息,具体操作如下

            1、查看CPU占用较高的进程ID

                   通过top命令,查看所有进程的CPU占用情况,如果知道是某个程序导致的CPU占用高的话,可以通过 ps -ef | grep '程序名称'查看相应的进程ID,如果,当前用户只启动了一个java程序,可以通过jps命令查看。获得进程ID的方式有很多,当时的操作是通过top命令获得。

            2、查看进程ID下CPU占用较高的线程

                  可以通过top -H -p PID查看对应进程的哪个线程CPU占用过高,也可以通过ps -mp PID -o THREAD,tid,time | sort -rn查看。

           3、获得线程ID的堆栈信息

                 首先需要将线程ID转换为16进程格式,具体可用printf "%x\n" TID,获得相应的值后,可通过如下命令打印线程的堆栈信息,jstack PID | grep TID -A 30,也可以写入到相应的文件中,jstack PID | grep TID -A 30 > temp.txt。也可以打印出进程ID下所有线程的堆栈信息,jstack PID > temp.txt。当时是打印出相应线程的堆栈,详细信息如下图


                

    具体原因

            从上图中可以定位到是那个类,那段代码的问题,于是就看那段代码,发现定义了一个静态的局部变量HashMap对象,而那段操作HashMap对象的代码,又是被多个线程同时操作,于是就网上搜了一下关于并发操作HashMap的后果的文章,结合JDK的源码,找到了原因,即,多并发操作HashMap会导致获取数据时死循环,下面解释为什么会出现死循环。

            HashMap的put方法具体实现代码如下:

        public V put(K key, V value) {
            if (key == null)
                return putForNullKey(value);
            int hash = hash(key.hashCode());
            int i = indexFor(hash, table.length);
           //如果该key已经被插入,则替换掉旧的value
            for (Entry<K,V> e = table[i]; e != null; e = e.next) {
                Object k;
                if (e.hash == hash && ((k = e.key) == key || key.equals(k))) {
                    V oldValue = e.value;
                    e.value = value;
                    e.recordAccess(this);
                    return oldValue;
                }
            }
    
            modCount++;
           //该key不存在,需要增加一个结点
            addEntry(hash, key, value, i);
            return null;
        }
        void addEntry(int hash, K key, V value, int bucketIndex) {
    	Entry<K,V> e = table[bucketIndex];
            table[bucketIndex] = new Entry<K,V>(hash, key, value, e);
           //查看当前的size是否超过了我们设定的阀值threshold,如果超过,需要resize操作
            if (size++ >= threshold)
                resize(2 * table.length);
        }
        void resize(int newCapacity) {
            Entry[] oldTable = table;
            int oldCapacity = oldTable.length;
            if (oldCapacity == MAXIMUM_CAPACITY) {
                threshold = Integer.MAX_VALUE;
                return;
            }
           //创建一个新的Entry数组
            Entry[] newTable = new Entry[newCapacity];
           //将Old Entry[]的数据迁移到New Entry[]上
            transfer(newTable);
            table = newTable;
            threshold = (int)(newCapacity * loadFactor);
        }
        void transfer(Entry[] newTable) {
            Entry[] src = table;
            int newCapacity = newTable.length;
           //从Old Entry[]里摘一个元素出来,然后放到new Entry[]中
            for (int j = 0; j < src.length; j++) {
                Entry<K,V> e = src[j];
                if (e != null) {
                    src[j] = null;
                    do {
                        Entry<K,V> next = e.next;
                        int i = indexFor(e.hash, newCapacity);
                        e.next = newTable[i];
                        newTable[i] = e;
                        e = next;
                    } while (e != null);
                }
            }
        }
            如果单线程执行相应的put方法并发生rehash操作时,不会发生什么问题,但是多线程同对统一HashMap进行rehash操作时,就会发生意向不到的问题。下面举例说明相应的问题。

            原来HashMap的数组是2,当里面再进行存放第三个元素时,就会发生rehash,此时原HashMap如下图

                         

            单线程进行rehash时,不会出现什么问题,会得到如下图所示的结果

                            

            多个线程进行rehash时,就会出现环形链接或丢失数据(可自己分析)的情况,下面以两个线程同时进行rehash时,出现环形链接现象的解释。

            线程一先执行,处理第一个元素key=3时,transfer方法执行到如下图中代码行时,线程被调度挂起来了,此时,线程一中,next指向的是key=7,e指向的是key=3。

                          

            线程二的rehash完成,此时Entry和Entry关系如下图,因为Entry和Entry之间的关系考的是引用维系的,所以,此时,线程二修改Entry和Entry之间的关系,其实,也作用与线程一看到Entry和Entry的关系。

                           

            线程二完成rehash后,线程一被调度回来执行,当线程一完成第一次循环后,结果如下图:

                                      

            线程一进入第二次循环时,此时的e指向的是key=7的entry,而此时的key=7的next指向的是key=3,所以,第二次完成后的结果如下图

                                 

            线程一进行第三次循环时,此时的e指向的是key=3的entry,而此时的key=3的next指向的是null(没有第四次循环了),所以,第三次完成后的结果如下图

                        

            最终HashMap会指向线程一的Entry[],此时,如果我们get一个值时,并且这个值正好在下标为3的元素中,并且,这个值不存在在HashMap中,此时,就会在key=3和key=7之间不停的循环,get的源码如下

        public V get(Object key) {
            if (key == null)
                return getForNullKey();
            int hash = hash(key.hashCode());
           //如果HashMap中没有这个值,并且,下标指向了3,并且3下标里面有环形链接,那么就会出现死循环
            for (Entry<K,V> e = table[indexFor(hash, table.length)]; e != null; e = e.next) {
                Object k;
                if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
                    return e.value;
            }
            return null;
        }

    解决问题

            找到问题的原因后,解决就比较简单了,可以使用线程安全的CurrentHashMap,也可以HashMap加锁,也可以换成每个线程单独一个HashMap对象,也可以换成其他的数据对象进行存取。

    总结

            定位问题时,查看代码发现使用了静态的HashMap对象,但是,当时并不认为是这个造成CPU过高,也就认为是正常业务的原因造成的CPU过高,没有再查(当时CPU也有往下降),等业务运行完成后,发现CPU换是那么高,才在网上继续搜,最终找到了原因,解决了问题。

            在这里需要反思,因为当时查到问题指向HashMap的get上时,自己却凭已有的认知说不可能发生这样的情况,于是推测CPU过高是业务正常运行造成的,真的是不该啊。当问题指向我们认为不该发生的点时,请一定要正式它,重视它,千万不要一口否决,不去重新认识它,因为,可能是我们的疏忽或对它认识的不全面,而导致我们现认为它不会带来这个问题。


    注:本文中出现的图片来自网上,本人仅做了微小调整。

    展开全文
  • HashMap并发下导致CPU

    千次阅读 2016-04-19 09:27:05
     然后用jstatck 48418 定位出线程堆栈48418换算成16进制是bd22,即与nid=0xbd22,可以看到是HashMap的问题,在并发情况下,使用HashMap会导致CPU的问题。 "[ACTIVE] ExecuteThread: '8' for queue: '...

      先用top命令定位哪些线程占用多:

    top - 18:14:46 up 200 days, 23:26,  2 users,  load average: 95.13, 88.59, 79.51
    Tasks: 1528 total,   1 running, 1525 sleeping,   1 stopped,   1 zombie
    Cpu(s): 98.3%us,  0.1%sy,  0.0%ni,  1.5%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
    Mem:  264351216k total, 178758300k used, 85592916k free,  1140796k buffers
    Swap: 16777208k total,        0k used, 16777208k free, 101647856k cached


      PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                           
    48418 weblogic  20   0 28.9g 5.1g  11m R 97.8  2.0  42:17.14 java  

      然后用jstatck 48418 定位出线程堆栈48418换算成16进制是bd22,即与nid=0xbd22,可以看到是HashMap的问题,在高并发情况下,使用HashMap会导致CPU 过高的问题。

    "[ACTIVE] ExecuteThread: '8' for queue: 'weblogic.kernel.Default (self-tuning)'" daemon prio=10 tid=0x00007f472000c000 nid=0xbd22 runnable [0x00007f479db6d000]
       java.lang.Thread.State: RUNNABLE
            at java.util.HashMap.getEntry(HashMap.java:465)
            at java.util.HashMap.containsKey(HashMap.java:449)
            at com.gg.component.common.aop.init.TransactionMethodUtil.getTxMode(TransactionMethodUtil.java:120)
            at com.gg.component.common.aop.proxy.TxProxy.doProxy(TxProxy.java:56)
            at com.gg.component.common.aop.ProxyChain.doProxyChain(ProxyChain.java:117)
            at com.gg.component.common.aop.ProxyManager.intercept(ProxyManager.java:57)
            at com.gg.sys.client.facade.ClientUserFacade$$EnhancerByCGLIB$$e4f7c867.queryUserDirectlyByOrgId(<generated>)
            at com.comtop.sproc.core.helper.SprocUserOrganizationHelper.queryUserInfosByOrgId(SprocUserOrganizationHelper.java:124)
            at com.comtop.lcam.fwms.safety.safetysupervise.controller.SupervisePlanController.updateSupervisionPlanPlanType(SupervisePlanController.java:714)
            at com.comtop.lcam.fwms.safety.safetysupervise.controller.SupervisePlanController$$FastClassByCGLIB$$5242a8b6.invoke(<generated>)
            at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
            at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:698)
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
            at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
            at com.comtop.lcam.fwms.monitor.MonitorAspect.aroundAllMethod(MonitorAspect.java:87)
            at sun.reflect.GeneratedMethodAccessor726.invoke(Unknown Source)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.lang.reflect.Method.invoke(Method.java:606)
            at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
            at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
            at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
            at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:80)
            at com.comtop.sproc.core.exceptionhandler.aop.SprocFacadeExceptionAspect.doAround(SprocFacadeExceptionAspect.java:45)
            at sun.reflect.GeneratedMethodAccessor555.invoke(Unknown Source)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.lang.reflect.Method.invoke(Method.java:606)
            at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:621)
            at org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:610)
            at org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:65)
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:161)
            at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
            at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
            at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:631)
            at com.comtop.lcam.fwms.safety.safetysupervise.controller.SupervisePlanController$$EnhancerByCGLIB$$19a36308.updateSupervisionPlanPlanType(<generated>)
            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
            at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
            at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
            at java.lang.reflect.Method.invoke(Method.java:606)
            at org.springframework.web.method.support.InvocableHandlerMethod.invoke(InvocableHandlerMethod.java:219)
            at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:132)
            at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:104)
            at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandleMethod(RequestMappingHandlerAdapter.java:745)
            at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:686)
            at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:80)
            at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:925)
            at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:856)
            at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:936)
            at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:838)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:751)
            at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:812)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:844)
            at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:280)
            at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:254)
            at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:136)
            at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:341)
            at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:25)
            at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
            at com.gg.sys.login.action.SessionFilter.doFilter(SessionFilter.java:219)
            at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
            at com.comtop.sproc.system.filter.SprocRequestFilter.doFilter(SprocRequestFilter.java:62)
            at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
            at com.gg.component.app.sna.SessionShareFilter.doFilter(SessionShareFilter.java:114)
            at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
            at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:88)
            at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
            at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
            at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
            at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:79)
            at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3388)
            at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3354)
            at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
            at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
            at weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
            at weblogic.servlet.internal.WebAppServletContext.doSecuredExecute(WebAppServletContext.java:2238)
            at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2154)
            at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2132)
            at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1564)
            at weblogic.servlet.provider.ContainerSupportProviderImpl$WlsRequestExecutor.run(ContainerSupportProviderImpl.java:254)
            at weblogic.work.ExecuteThread.execute(ExecuteThread.java:312)
            at weblogic.work.ExecuteThread.run(ExecuteThread.java:264)


    解决方案:

    If multiple threads access a  HashMap concurrently and modify the map, it must be synchronized externally
    To resolve this issue of corrupt  HashMap caused by asynchronous concurrent access is to do either of the following:
    1. Synchronize objects using the  HashMap
    OR
    2. Implement Concurrent HashMap instead of  HashMap.

    展开全文
  • 今天在生产环境遇到一个问题,Java 应用程序的 cpu 使用比例很,导致整台机器的 cpu 使用率高达 90% ,正常情况下是 20% 左右。 把 Thread dump 导出来,利用 IBM Thread Analyzer for Java 工具进行分析。总共有...

     今天在生产环境遇到一个问题,Java 应用程序的 cpu 使用比例很高,导致整台机器的 cpu 使用率高达 90% ,正常情况下是 20% 左右。

    把 Thread dump 导出来,利用 IBM Thread Analyzer for Java 工具进行分析。总共有60 多个在线线程,其中有 15 个线程都在执行同一个文件中的同一句代码,最顶层的调用是 HashMap.get() 。

    HashMap 的底层数据结构是数组 + 链表进行存储,链表用于处理 hash 碰撞的情况。正常情况下链接是线性链表,当数据结构在并发情况下被污染了,导致出现环形链表,则会出现程序的无限循环。

    15 个线程在同一时间都在执行同一行代码,是很不正常的情况。当线程调用 HashMap.get 并在链表上搜索时,碰巧遇到的是被污染的环形链接,就能解释得通这个异常情况了。

    HashMap 是非线程安全,在多线程并发访问时,有可能出现环形链表。详细且清晰的分析,参考:

    A Beautiful Race Condition

    Explain the timing causing HashMap.put() to execute an infinite loop

     

    附:关于 HashMap 源码阅读笔记

    Map / HashMap - 源代码学习笔记

    转载于:https://www.cnblogs.com/TonyYPZhang/p/6041312.html

    展开全文
  • HashMap导致CPU100% 的分析
  • JAVA中hashmap.get()导致CPU占用过问题

    千次阅读 2012-06-29 15:11:40
    我们的Java代码中用到太多的HashMap类,用到了太对这个类的get()方法,但是在Jdk1.5.0之前我可以告诉你hashmap.get()方法存在死循环的情况并导致CPU占用持续,也许你会很惊讶。 以下是JDK 1.5.05和JDK 1.5.1中...

           我们的Java代码中用到太多的HashMap类,用到了太对这个类的get()方法,但是在Jdk1.5.0之前我可以告诉你hashmap.get()方法存在死循环的情况并导致CPU占用持续高,也许你会很惊讶。
    以下是JDK 1.5.05和JDK 1.5.1中HashMap的源码比较:
    From JDK 1.5.05, HashMap.java:

        public V get(Object key) {

            Object k = maskNull(key);

            int hash = hash(k);

            int i = indexFor(hash, table.length);

            Entry<K,V> e = table;

            while (true) {

                if (e == null)

                    return null;

                if (e.hash == hash && eq(k, e.key))

                    return e.value;

                e = e.next;

            }

        }

     

    From JDK 1.5.12: HashMap.java:

        public V get(Object key) {

                if (key == null)

                    return getForNullKey();

            int hash = hash(key.hashCode());

            for (Entry<K,V> e = table[indexFor(hash, table.length)];

                 e != null;

                 e = e.next) {

                Object k;

                if (e.hash == hash && ((k = e.key) == key || key.equals(k)))

                    return e.value;

            }

            return null;

        }

            所以如果没有正确的使用Hashmap,这确实会发生的,从而会导致某些程序一直在高CPU下长时间运行。因为Hashmap是非线程安全的。从老版本Jdk的hashmap.get()方法实现可以看出如果你在使用Hashmpa是在外部作了同步,这个问题永远也不会发生。我们了解了这个问题,可以在我们平时开发时注意避免这个问题的发生,但有很多我们使用的第三方开源的包有时也存在误使用了Hashmap导致了该问题的发生,例如Hibernate就有该问题。所以最好的办法就是将你的Jdk版本升级到jdk1.5.0以上。


     

    展开全文
  • 当利用非线程安全的方式访问HashMap时,会导致CPU 或 过多线程挂起 kill -3 pid java -jar jca457.jar  打开: javacore文件javacore.20160920.085924.26934.0004.txt     堆栈表现不同 at java.util...
  • 多线程环境下HashMap导致CPU100%

    千次阅读 2020-07-09 09:31:54
    昨天早上线上系统开始作业了一段时间以后,突然收到服务器报警,服务器CPU持续占用100%,导致线上系统不能正常使用,我登录服务器top了一下,发现java进程占用cpu400%, 由于前天晚上上线了一些新的功能,所以我分析...
  • import java.util.HashMap; import java.util.Map; public class HashMapMultiThread { static Map map = new HashMap(); public static class AddThread implements Runnable{ int start = 0 ; public Ad
  • HashMap

    2019-08-07 17:37:47
    HashMap为什么不是线程安全的? 多线程操作无并发控制,顺便说了在扩容的时候多线程访问时会造成死锁,会形成一个环 怎么让HashMap变得线程安全? Collections的synchronize方法包装一个线程安全的Map,或者直接用...
  • HashMap cpu占用 100%

    2012-11-10 22:22:57
    今天在重现出HashMap cpu占用100%了,只要并发稍微大一点就会出现,我用一个本地HashMap mock一个Memcached的客户端,通过netty暴露结果中招了:下面是打印的jstack:     jstack 写道 Full thread dump Java ...
  • HashMap死循环,CPU100%

    2017-08-24 10:40:45
    在淘宝内网里看到同事发了贴说了一个CPU被100%的线上故障,并且这个事发生了很多次,原因是在Java语言在并发情况下使用HashMap造成Race Condition,从而导致死循环。这个事情我4、5年前也经历过,本来觉得没什么好写...
  • 并发场景下HashMap.get导致cpu耗光

    千次阅读 2013-06-29 21:40:49
    Java中HashMap.get导致cpu耗光bug,是由于HashMap.get里面的for循环出现了无限循环,出现死循环是因为map中的桶链表出现了循环链表,循环链表是因为并发put操作造成的,同时进行了resize();如果只有一个线程进行put...
  • 1.top命令查出占用cpu高的进程pid 2.使用jstack -l pid >dump.txt 获取dump文件 3.使用top -H查询出消耗资源的线程号tid(十进制线程id),转换为16进制 4.cat dump.txt | grep -10 tid(16进制) 查...
  • 一个应用集群里,时不时会有几台机器出现cpu打满现象,开始没有引起重视,后来连续出现报警,开始着手对其中一台进行排查,现将破案记录如下。 cpu飙升这类案件,一般来说有几个对象嫌疑重大: 嫌犯A:内存泄漏,...
  • 一篇技术含量非常的多线程下HashMap死循环造成cpu100%的研究文章 http://www.iteye.com/topic/962172
  • HashMap如何导致CPU100%的?

    千次阅读 2021-02-01 11:15:40
    一、HashMap的数据结构? JDK7:数组+链表 JDK8:数组+链表+红黑树 1.1 数组的存储特点 查询:连续性,有下标,查询速度快。 插入:后面的节点需要全部移动,时间复杂度。 删除:节点下标全部需要改变,除了最后一个...
  • 后来,我们的程序性能有问题,所以需要变成多线程的,于是,变成多线程后到了线上,发现程序经常占了100%的CPU,查看堆栈,你会发现程序都Hang在了HashMap.get()这个方法上了,重启程序后问题消失。但是过段时间又会...
  • hashmap在多线程下,形成死循环的原因:请参考:https://blog.csdn.net/xiaohui127/article/details/11928865jdk1.8以后解决了此问题!请参考:https://blog.csdn.net/xzongyuan/article/details/72615862...
  • 最近的几次面试中,我都问了是否了解HashMap在并发使用时可能发生死循环,导致cpu100%,结果让我很意外,都表示不知道有这样的问题,让我意外的是面试者的工作年限都不短。 由于HashMap并非是线程安全的,所以在...
  • 使用jstack做了dump,发现如下stack,原来是servlet中访问HashMap是非同步的。 "http-80-136" daemon prio=10 tid=0x7e59c000 nid=0x1b1 runnable [0x794e1000..0x794e1db0] java.lang.Thread.State: ...
  • 使用HashMap线程不安全造成CPU 100%

    千次阅读 2015-04-28 10:35:51
    最近应用服务器总时不时的报CPU 100%,是多个CPU 100%。最后查出是aspectjweaver这个jar包中用到了HashMap是线程不安全的。 POST /web/gg/workflow/fore/DoSpecialForeSubmit.jsp?isProgress=false HTTP/1.1 X-...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 58,683
精华内容 23,473
关键字:

cpu高hashmap