性能测试之：一次线程不安全导致的死循环

性能测试场景： 发送3条HTTP请求给服务器，服务器响应请求有2条是同步响应，有1条是异步响应。3个请求分别为3个事务。 测试过程中的现象： 1、第一个场景做性能测试时，场景运行为15分钟，运行正常，各项指标也正常。做了3次同场景测试之后，确定性能测试通过。 2、第二个场景做疲劳测试，场景运行半个小时之后，服务器CPU突然升高到100%，load average持续很高。而且在压力停止之后很长一段时间，CPU利用率仍然100%，load average仍然很高。 分析问题，解决： 1、分析问题： 通过上述现象，使用VisualVM工具，查看线程dump，发现里面有大量线程block。但是通过线程无法具体定位到那段代码。 为了精确定位引起线程block的代码，将3条Http请求进行分解，并分别测试，发现是第2条http请求引起的线程block。就下来的事情相对测试就简单了，主要是我们的开发人员进行代码分析，如果导致线程block了。 2、最终定位问题和解决： 开发同事定位问题：HashMap 对象不是线程安全的，在并发调用的时候容易造成程序死循环。从而导致CPU100%，且压力停止之后，CPU仍然100%，也非常符合上述场景测试结果。 解决方案： （1）、HashMap不是线程安全的。 （2）、在并发的场合需要使用ConcurrentHashMap对象（读多写少）。    最新内容请见作者的GitHub页：http://qaseven.github.io/
记一次并发引起的问题及排查过程 聚合支付系统（第四方支付），协议支付模块一直有个小问题。 商户调用协议支付接口，该模块会调用下层第三方支付渠道的协议支付服务，如果第三方支付渠道没有同步返回支付结果，则协议支付模块会通过定时任务向第三方支付渠道批量第查询支付结果（每查一笔订单就调一次第三方支付渠道，“批量”相当于并发调用第三方支付渠道）
看山聊并发：面试实战之多线程顺序打印 这个问题考察的是多线程协同顺序执行。也就是第一个线程最先达到执行条件，开始执行，执行完之后，第二个线程达到执行条件，开始执行，以此类推。可以想到的是，通过状态位来表示线程执行的条件，多个线程自旋等待状态位变化。
排查程序死循环，死锁的方法 ——pstack pstack命令可显示每个进程的栈跟踪，pstack $pid即可，pstack命令须由$pid进程的属主或者root运行。 这次出现cpu占比100%的情况，但看memory占比，并无异常，怀疑是某个地方死循环了。