51CTO博客开发
从我的前一篇博文中, 我们知道了CPU缓存及缓存行的概念, 同时用一个例子说明了编写单线程Java代码时应该注意的问题. 下面我们讨论更为复杂, 而且更符合现实情况的多核编程时将会碰到的问题. 这些问题更容易犯, 连j.u.c包作者Doug Lea大师的JDK代码里也存在这些问题. MESI协议及RFO请求 从前一篇我们知道, 典型的CPU微架构有3级缓存, 每个核都有自己私有
众所周知, CPU是计算机的大脑, 它负责执行程序的指令; 内存负责存数据, 包括程序自身数据. 同样大家都知道, 内存比CPU慢很多. 其实在30年前, CPU的频率和内存总线的频率在同一个级别, 访问内存只比访问CPU寄存器慢一点儿. 由于内存的发展都到技术及成本的限制, 现在获取内存中的一条数据大概需要200多个CPU周期(CPU cycles), 而CPU寄存器一般情况下1个CPU周期就够
从Java视角理解系统结构连载, 关注我的微博(链接)了解最新动态 在高性能编程时,经常接触到多线程. 起初我们的理解是, 多个线程并行地执行总比单个线程要快, 就像多个人一起干活总比一个人干要快. 然而实际情况是, 多线程之间需要竞争IO设备, 或者竞争锁资源，导致往往执行速度还不如单个线程. 在这里有一个经常提及的概念就是: 上下文切换(Context Switch). 上
hi，all 最近抽时间把JVM运行过程中产生的一些线程进行了整理，主要是围绕着我们系统jstack生成的文件为参照依据。 前段时间因为系统代码问题，造成性能瓶颈，于是就dump了一份stack出来进行分析。 stack 里面线程非常多，排查起来需要一定的经验，所以，对它们有一定了解，可以提高排查问题的效率。
做得好都是相似的 做得不好的。。。各有各的原因 1阶段 – 悄悄进去，不要打扰 可用性，性能，团队稳定，客户稳定
一个应用在周五出现java进程消失，没有任何日志。先查看/var/log/message中无oom_killer信息，所以只能拿core。 该应用是一个集群，通知他们将出现crash的服务器上打开ulimit,等待生成core文件 。 今天周一，下午应用负责人紧急找我，说同时出几台crash了。开了ulimit参数的那台服务器coredump已经生成。 登录到该服务器上，先是gdb $J
Copyright © 2005-2024 51CTO.COM 版权所有 京ICP证060544号
