读懂 thread heap

  1. 第一行是线程基本信息, 分别是 线程名字, 是否是Daemon线程(如果不是就不显示), 线程优先级, 线程id, OS native 线程id, 当前运行的状态[当前在那个对象对象].

  2. 当前线程的状态

  3. 下面就是当前线程的Stack;

    "DefaultThreadPool-89" daemon prio=10 tid=0x00007f3974036000 nid=0xb4a waiting on condition [0x00007f393e7e4000]
    java.lang.Thread.State: WAITING (parking)
    at sun.misc.Unsafe.park(Native Method)
    - parking to wait for <0x00000007ac99baf8> (a com.ebay.raptor.orchestration.impl.FutureCallableTask)
    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
    at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:425)
    at java.util.concurrent.FutureTask.get(FutureTask.java:187)

  4. Java 线程有6种状态: New, Runnable, Blocked, Waiting, Timed Waiting, Terminated. 对应到 thread dump 里面: 到现在做的 thread dump 里面没有看到状态是 New的. 也没有看到 Terminated 的. 其它都看到过:
    java.lang.Thread.State: RUNNABLE

java.lang.Thread.State: BLOCKED (on object monitor)

java.lang.Thread.State: TIMED_WAITING (sleeping)
java.lang.Thread.State: TIMED_WAITING (parking)
java.lang.Thread.State: TIMED_WAITING (on object monitor)

java.lang.Thread.State: WAITING (parking)
java.lang.Thread.State: WAITING (on object monitor)

  1. JVM 6种线程定义:

    A thread state. A thread can be in one of the following states:
    NEW
    A thread that has not yet started is in this state.
    RUNNABLE
    A thread executing in the Java virtual machine is in this state.
    BLOCKED
    A thread that is blocked waiting for a monitor lock is in this state.
    WAITING
    A thread that is waiting indefinitely for another thread to perform a particular action is in this state.
    TIMED_WAITING
    A thread that is waiting for another thread to perform an action for up to a specified waiting time is in this state.
    TERMINATED
    A thread that has exited is in this state.
    A thread can be in only one state at a given point in time. These states are virtual machine states which do not reflect any operating system thread states.

  2. 什么情况下会进入 blocked 状态?
    根据 Thread.State 类的描述: 1. 当一个线程在准备进入Synchronized的块/方法的时候, 2. 或者该线程之前已经进入synchronized 块/方法, 之后又call 了 Object.wait, 这个时候, 该线程进入 Waiting状态 或者 timed_waiting 状态, 之后又被 notify 或notifyAll 唤醒, 等待重新进入Synchronized同步块/方法, 这时候又进入blocked 状态.

  3. 什么情况会进入 waiting 状态?
    等待某种事件发生.
    Object.wait with no timeout -> 等待notify 或 notifyAll
    Thread.join with no timeout -> 等待特定线程终止
    LockSupport.park -> 等待 unpark

  4. 什么情况会进入 timed_waiting 状态?
    虽然等待某种特殊事件发生, 不过最多只等待特定时间
    Thread.sleep
    Object.wait with timeout
    Thread.join with timeout
    LockSupport.parkNanos
    LockSupport.parkUntil

强制 chrome browser 下载 而不是 打开

-- 尚未解决 --

问题: 经常下载一些比较大的文件, 如JVM heap, 通常几个G, 然而常用的chrome 浏览器的默认行为竟然是打开, 而不是下载, 直接导致它开始卡住, 继而电脑开始嗡嗡响.

有用的链接:
https://chromium.googlesource.com/chromium/src/+/500057e7dc62bc041d248c03e10e73165d044e3e/chrome/browser/download/download_prefs.cc
https://superuser.com/questions/408243/prevent-chrome-from-automatically-opening-downloaded-pdf-and-image-files
https://superuser.com/questions/725854/prevent-chrome-from-automatically-opening-files
https://support.google.com/chrome/forum/AAAAP1KN0B07MMOjnYxV4Q/?hl=en&gpf=%23!topic%2Fchrome%2F7MMOjnYxV4Q
https://stackoverflow.com/questions/20144948/is-there-any-way-to-programatically-force-always-open-files-of-this-type-for-a

Sony 电子书 digital paper rp1 使用感受

刚工作的时候, 为了学习各种技能, 买了很多书, 后来每次搬家, 发现最难搬的就是哪些厚厚的书, 里面有一大部分是买过之后根本没读过的. 反而很多存的电子书都读过不少. 在第二家公司离职之前, 发现电脑里存了至少10几个G的各种格式的书, 最多的是pdf, 当时还很喜欢收集各种 chm 格式的书, 尽管有人说 chm 格式可能有携带病毒的风险, 不过鉴于个目录结构非常清晰, 如果有 chm 格式的, 绝对不会看其它的. 那次离职之前把当时所有的电子书都上传到了 download.csdn.net. 于是我的csdn账号成了一个非常受欢迎的东西, 因为后来 csdn在下载东西需要积分, 而我那个账号因为分享了好些书, 别人下载我可以自动有积分, 于是很多同事都喜欢用我那个含有很多积分的csdn账号下东西.

尽管 chm 格式很好, 不过哪些都是些 速查工具手册 之类的, 比如 CSS, HTML, SQL 语法之类的. 更多系统性的书和文档都是pdf 格式的.

后来处于保护眼睛和便携性, 买了 Kindle paperwhite, 发现这确实是个好东西, 不伤眼, 可以在灯光昏暗的地方看, 方便携带, 还有 amazon 里面的很多书可以买.

对于很多计算机方面的书有个问题是, 里面的很多插图, 很多代码, 放到 Kindle 里面的效果很不好, 看起来格式就很乱. 另外一方面Safari online 里面的很多书只能导出pdf格式. 尽管有很多切边的教程可以把pdf 放到 Kindle, 但是效果很不好.

后来了解到电子书, 当时国内外已经有很多这样的设备, 考虑到Kindle同样的屏幕大小的问题, 想买一个尽量大屏幕的设备. 查找过很多资料, 说最大屏幕, 最好效果的竟然是Kindle 家族已经停产的 Kindle DXG. 于是在淘宝上买了一个二手的(当时只有二手可买). 收到之后发现屏幕上面有好几处明显的划痕, 大概1200多块钱. 我老婆看后觉的不划算, 要退货. 我说如果退了这个, 只能买一个快要发布的Sony的电子书, 那个要5000多块钱, 她觉的5000多买个新的也比这个有划痕, 已经停产好几年的东西强, 于是在2017年8月从亚马逊上面海淘了一个美版的 Sony Digital Paper rp1.

到现在已经使用了大概1年半多, 读了至少有20多本书, 大部分是计算机相关的. 使用的感受如下:

  1. 大屏幕确实是我最喜欢的, 略比 A4 纸大一点点, 完全是为了看pdf 而生的, 很轻薄, 手感很不错.
  2. 省电, 我基本是关掉Wi-Fi, 关掉蓝牙, 传文件的时候使用USB, 不关机, 待机至少3周吧, 看书的情况下, 和你看的时间有关, 基本看的话, 能看很长时间, 没有测试过, 至少8个小时绝对有. 另外和你在上面用笔划的多少也有关.
  3. 破解 有人说它的硬件性能其实很好, 可是Sony 只让它看pdf 有点浪费, 要破解装其它基于android的系统, 我并么有这个需求, 我就是用它来看pdf. 看网上有人说破解之后, 耗电非常快;
  4. 手机app, 后来升级之后, 它可以连手机app 了, 我么有使用过;
  5. 软件升级. 最开始它的软件很弱, 连页数跳转都没有. 后来出来一个软件更新, 不过那个更新很麻烦, 要先删除电脑digital paper 软件, 然后安装最新版本的电脑 digital paper app 才能升级电子书软件;
  6. 另外使用比较舒适的是, 你做的笔记可以擦掉, 比如一本书你看很多遍, 后面看的时候, 会把之前看的时候的笔记擦除, 这个很方便;
  7. 笔 那个笔的笔尖是个易耗品, 我大概第一个笔尖只使用了1个月, 可能做的笔记比较多. 后来去美国的时候, 专门又买了10个笔尖. 另外又一次有个笔尖竟然断到里面, 幸亏很容易就拔出来了;
  8. 笔触的粗细 它能调节笔尖的粗细, 不过即使同一个粗细程度, 在不同的pdf 文件上最终的粗细程度并不一样, 有时候要根据pdf 的文字内容大小 去调节笔触的粗细;
  9. 屏幕没有灯光, 这个是对比Kindle 很弱的一个方面, 这意味这你一定要在灯光明亮的地方看, 否则很费眼. 本身电子书没有光, 不像Kindle 一样 内置灯光, 所以我基本只在台灯下看;
  10. 不方便携带, 对比Kindle 可以放进口袋, 这个真的不方便携带. 我基本把它和Mac放一个笔记本包, 不过有次我还是看到有个边上竟然接缝处错开了, 不过我稍微纠正一下, 又回复原样了;

下一步 如果可以的话, 在买个 10.3寸的做收藏.

由 hypervisor 驱动内存泄漏导致的 VM CPU飙高的问题

今天有开发人员说他们同一个 cluster 里面运行同一版本的某些 server 出现 JVM CPU 非常高的情况, 而其它 server 的JVM
CPU 维持正常. 他们表示说以前没出现过这种情况, 而出现这种情况的server 比正常其它server 的CPU usage 要高很多, 所以被内部某些监控工具自动重启了. 据他们观察这些机器可能正在被内部的某些漏洞扫描工具在扫描, 但是又不能确认, 想请SRE帮忙确认一下原因是什么?

SRE 首先确认了这些 CPU usage 非常高的server 跟内部的漏洞扫描基本没关系, 因为这些漏洞扫描的 traffic 基本进不了程序内部代码逻辑, 在应用框架层就被拦截了, 基本不会造成CPU usage 高. 另外还有其它被漏洞扫描的server 并没有出现 CPU 飙高的情况.

SRE 另外明确看到, 这些出问题的server(其实都是通过OpenStack 虚拟出来的VM)的CPU usage大概都在40%左右, 不出问题的server 的CPU usage 大概在3%左右. 出问题server 的JVM CPU usage 大概在8%左右, 而没有问题的 server 的 JVM CPU usage 大概在1%左右. 所以可以大概得出结论, 这些CPU 大部分并不是被 JVM 所占用, 但是 JVM 也受到了一定的影响.

进一步观察发现出现问题的server 都是在同一台 hypervisor 上, 进一步去查看同一台 hypervisor 上面的其它 vm server, 也都表现出了 CPU 较高的情况.

登录到这台 Hypervisor 上面, 使用下面的命令可以看到, 这些Hypervisor 有kernel的内存泄漏问题:

admin@hv-8hhy:~$ smem -twk
Area                           Used      Cache   Noncache
firmware/hardware                 0          0          0
kernel image                      0          0          0
kernel dynamic memory        159.2G       6.5G     152.7G
userspace memory             139.3G     196.2M     139.1G
free memory                   15.6G      15.6G          0
----------------------------------------------------------
                             314.1G      22.3G     291.8G

在 kernel dynamic memory 这行的 Noncache 这列, 我们看到它使用了152.7G, 这明显是个问题. 对于 Cloud team来说这是一个已知的issue, 并且给出了 kernel 的fix link:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/drivers/net/ethernet/intel/i40e/i40e_txrx.c?id=2b9478ffc550f17c6cd8c69057234e91150f5972