<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[spytian的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/spytian</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; spytian]]></copyright><item><title><![CDATA[Java 的线程到底占用了多少内存?]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/113637759</link><guid>https://blog.youkuaiyun.com/spytian/article/details/113637759</guid><author>spytian</author><pubDate>Thu, 04 Feb 2021 12:45:44 +0800</pubDate><description><![CDATA[原文排版比较好.   原文链接:https://mp.weixin.qq.com/s/wA3pUemz5oWJX6Zp9HFIGA





若是有人问你正在运行的Java 程序的堆占用了多少内存, 你一个命令就给出了答案; 若是有人问你正在运行的 Java 程序的线程栈使用了多少内存, 该怎么得到答案呢?



故事背景

 有人的 Java 程序遇到了 OOM,程序崩溃之前,只给出了这么一句关键遗言: "java.lang.OutOfMemoryError: unable ...]]></description><category></category></item><item><title><![CDATA[谁吃掉了 Java 异常的代码栈?]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/113602394</link><guid>https://blog.youkuaiyun.com/spytian/article/details/113602394</guid><author>spytian</author><pubDate>Wed, 03 Feb 2021 14:12:12 +0800</pubDate><description><![CDATA[转自:https://mp.weixin.qq.com/s/GUFvhOtJMg4tAdMVDWI8bA



原创有趣的bug代码中那些有趣的bug今天

  通常情况下, 如果我们遇到某些异常, 都把出错异常栈打出来, 这样方便查看到底哪行代码出错了,是怎么一层层调用到了这行代码. 可是有时候,虽然我们明确写了打印出错异常栈, 可是偏偏日志里面却没有出错栈, 这是怎么一回事呢?



故事背景

  某天, 有开发人员找到 SRE 说, 他们的代码出了一个新的空指针错误...]]></description><category></category></item><item><title><![CDATA[JVM 的 “VM Thread“ 线程]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/108230812</link><guid>https://blog.youkuaiyun.com/spytian/article/details/108230812</guid><author>spytian</author><pubDate>Tue, 25 Aug 2020 23:13:27 +0800</pubDate><description><![CDATA[最近在帮一个同事看一个 Java 应用为什么会被经常重启的时候, 定位到 Java 应用中一个线程经常以 CPU 使用率100%的方式出现在 htop 的头部, 它是什么线程, 为什么会导致一个 CPU 100%? 这引起了我的兴趣.

相关背景及症状表现

这个应用程序运行中一个有8个 CPU 的 VM 上面, 经常看到该应用程序已最低13%的使用率运行, 有时候CPU 使用率会突然升到100%, 不过大多数会以13%或稍高来运行. 从 htop 的结果可以看到, 主要一个是一个线程导致一个 CPU 10]]></description><category></category></item><item><title><![CDATA[Java 无法 attach 到目标进程, 使用 core dump 转换为 Java heap dump]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/108161410</link><guid>https://blog.youkuaiyun.com/spytian/article/details/108161410</guid><author>spytian</author><pubDate>Fri, 21 Aug 2020 23:32:07 +0800</pubDate><description><![CDATA[有时候, 当我们尝试对一个已经 GC overhead 非常高的 Java 应用进程去做 heap dump 的时候, 发现我们跟没办法 attach 到目标 Java 进程, 得到下面的错误:


/usr/bin/jcmd 7674 GC.heap_dump /tmp/heap.log.hprof
7674:
com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file: target process not r]]></description><category></category></item><item><title><![CDATA[诊断 Java 由 Synchronizer 和 AQS 混合组成的死锁]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/104721279</link><guid>https://blog.youkuaiyun.com/spytian/article/details/104721279</guid><author>spytian</author><pubDate>Sat, 07 Mar 2020 20:30:41 +0800</pubDate><description><![CDATA[原文链接:http://www.tianxiaohui.com/index.php/SRE/%E8%AF%8A%E6%96%AD-Java-%E7%94%B1-Synchronizer-%E5%92%8C-AQS-%E6%B7%B7%E5%90%88%E7%BB%84%E6%88%90%E7%9A%84%E6%AD%BB%E9%94%81.html

死锁问题在 SRE 的日常的应用诊断中, 经...]]></description><category></category></item><item><title><![CDATA[SRE重案调查组 第六集 | 剖析Java的非常规线程死锁问题]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/103098338</link><guid>https://blog.youkuaiyun.com/spytian/article/details/103098338</guid><author>spytian</author><pubDate>Sat, 16 Nov 2019 14:29:48 +0800</pubDate><description><![CDATA[原文链接:https://mp.weixin.qq.com/s/r__X4sYj6PLjPDWDulJAAw



供稿 | eBay Infrastructure Engineering

翻译&amp;编辑 | 顾欣怡

本文共3609字，预计阅读时间11分钟

更多干货请关注“eBay技术荟”公众号



导读

本文将分享eBay SRE部门遇到的某个非常规Java应用程序死锁问题。...]]></description><category></category></item><item><title><![CDATA[SRE重案调查组 第五集 | 为什么我的服务器又双叒不响应了？！]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/103098329</link><guid>https://blog.youkuaiyun.com/spytian/article/details/103098329</guid><author>spytian</author><pubDate>Sat, 16 Nov 2019 14:29:04 +0800</pubDate><description><![CDATA[原文地址:https://mp.weixin.qq.com/s/-CTHVLxgzTn79vOqEe_CQQ

供稿 | eBay Infrastructure Engineering

翻译&amp;编辑 | 顾欣怡

本文共3892字，预计阅读时间12分钟

更多干货请关注“eBay技术荟”公众号



导读

  在SRE的日常工作中,经常会碰到很多典型问题。其中一种便是:为什么我的...]]></description><category></category></item><item><title><![CDATA[SRE重案调查组 第四集 | JVM元数据区的内存泄漏之谜]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/103098310</link><guid>https://blog.youkuaiyun.com/spytian/article/details/103098310</guid><author>spytian</author><pubDate>Sat, 16 Nov 2019 14:28:09 +0800</pubDate><description><![CDATA[原文链接:https://mp.weixin.qq.com/s/h8ayDuk7SSQ-0-jNmGmydw



供稿 | eBay Infrastructure Engineering

翻译&amp;编辑 | 顾欣怡

本文共2155字，预计阅读时间7分钟

更多干货请关注“eBay技术荟”公众号



导读

从Java 8开始，元数据区(Metaspace)被引入，替换永久代...]]></description><category></category></item><item><title><![CDATA[SRE重案调查组 第三集 | 探秘HTTP异步请求的“潘多拉魔盒”]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/103098011</link><guid>https://blog.youkuaiyun.com/spytian/article/details/103098011</guid><author>spytian</author><pubDate>Sat, 16 Nov 2019 14:01:33 +0800</pubDate><description><![CDATA[原文地址:https://mp.weixin.qq.com/s/kVA4vrrk-UbttChu2zhaFA



供稿 | eBay Infrastructure Engineering

翻译&amp;编辑 | 顾欣怡

本文共3365字，预计阅读时间11分钟

更多干货请关注“eBay技术荟”公众号



导读

HttpAsyncClient是基于Httpcore NIO 和H...]]></description><category></category></item><item><title><![CDATA[SRE重案调查组 第二集 | 挖掘应用处理变慢的“真相”]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/103097961</link><guid>https://blog.youkuaiyun.com/spytian/article/details/103097961</guid><author>spytian</author><pubDate>Sat, 16 Nov 2019 13:56:54 +0800</pubDate><description><![CDATA[原文地址:

https://mp.weixin.qq.com/s/Sh7ddc-3mGXWCGppi50EHg

供稿 | eBay InfrastructureEngineering

翻译&amp;编辑 | 顾欣怡

本文共1942字，预计阅读时间6分钟

更多干货请关注“eBay技术荟”公众号



导读

eBay SRE部门经常处理生产环境中各种各样的疑难杂症，此次探究的是应用处...]]></description><category></category></item><item><title><![CDATA[高延迟问题的罪魁祸首System.gc()]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/103097793</link><guid>https://blog.youkuaiyun.com/spytian/article/details/103097793</guid><author>spytian</author><pubDate>Sat, 16 Nov 2019 13:40:39 +0800</pubDate><description><![CDATA[原文地址:https://mp.weixin.qq.com/s/Ivtfu4bH5vVd0KiAOonoCA

导读

eBay SRE每天都处理生产环境中出现的各种各样的问题,有些问题很具有代表性，这次我们将分享与Java语言中System.gc()相关的两个典型案例，介绍如何分析这种问题，并且如何定位且修复这些问题。

01

案例一:

某日，支付平台的开发人员找到SRE,需要SRE帮助...]]></description><category></category></item><item><title><![CDATA[诊断 puppet agent 导致的 CPU 使用率非常高的问题]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/101859627</link><guid>https://blog.youkuaiyun.com/spytian/article/details/101859627</guid><author>spytian</author><pubDate>Tue, 01 Oct 2019 19:19:43 +0800</pubDate><description><![CDATA[问题描述:
看到有一台机器表现很突出, CPU 使用率比其它高, 干活却没比其它机器多:

搜集数据:
登录机器, 查看各个进程 CPU 使用情况: 以 root 运行的 puppet 就是那个嫌疑犯
top -i
嫌疑犯近照:
ps -auxwwww

因为 strace 只针对一个线程, 如果一个进程里面有多个线程, 首先要查出是哪个线程使用 CPU 比较高, 否则可能出错.
使用 top -...]]></description><category></category></item><item><title><![CDATA[使用 strace 解决 twagent 狂耗 CPU 问题]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/101859537</link><guid>https://blog.youkuaiyun.com/spytian/article/details/101859537</guid><author>spytian</author><pubDate>Tue, 01 Oct 2019 19:18:28 +0800</pubDate><description><![CDATA[最近一段时间, 经常发现生产环境上有些服务器的 CPU 使用率比其它高很多. 检查下来, 都不是我们自己的应用程序导致的, 细分下来有两种, 一种是 puppet agent 导致的(诊断 puppet agent 导致的 CPU 使用率非常高的问题), 另外一种就是 twagent 导致的.


	首先, 通过 top -i -H 可以看到这个进程十分耗 CPU
	
	
	然后, 通过 ps a...]]></description><category></category></item><item><title><![CDATA[错误的 ExecutorService 用法导致的内存泄露]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/94395836</link><guid>https://blog.youkuaiyun.com/spytian/article/details/94395836</guid><author>spytian</author><pubDate>Mon, 01 Jul 2019 16:14:56 +0800</pubDate><description><![CDATA[原文链接:http://www.tianxiaohui.com/index.php/interestingbug.html

JDK 提供了 ExecutorService 接口以及默认的实现类, 并通过 Executors 工具类暴露了一些常见的用法. 如果使用不当, 将会很容易造成线上问题. 这里介绍一个曾经遇到的这样的问题.

一开始看到了某个应用里面的一台机器开始 GC overhead...]]></description><category></category></item><item><title><![CDATA[如何确诊由 HashMap 引起的 死循环问题]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/93723435</link><guid>https://blog.youkuaiyun.com/spytian/article/details/93723435</guid><author>spytian</author><pubDate>Wed, 26 Jun 2019 11:28:55 +0800</pubDate><description><![CDATA[原文链接:http://www.tianxiaohui.com/index.php/interestingbug.html

Java 开发者都知道 java.util.HashMap 是非线程安全的, 一旦涉及多线程情况使用同一个 Map, 除非做了其他同步, 否则都不应该使用 HashMap. 然而现实情况是: 时不时发现生产环境在多线程情况下使用了 HashMap, 导致死循环, 继而不再...]]></description><category></category></item><item><title><![CDATA[狂打出错日志导致的 CPU 飙升]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/93419042</link><guid>https://blog.youkuaiyun.com/spytian/article/details/93419042</guid><author>spytian</author><pubDate>Sun, 23 Jun 2019 23:13:37 +0800</pubDate><description><![CDATA[原文链接:

http://www.tianxiaohui.com/index.php/Java%E7%9B%B8%E5%85%B3/%E7%8B%82%E6%89%93%E5%87%BA%E9%94%99%E6%97%A5%E5%BF%97%E5%AF%BC%E8%87%B4%E7%9A%84-CPU-%E9%A3%99%E5%8D%87.html



程序中输出日志, 是正常普通的事情, ...]]></description><category></category></item><item><title><![CDATA[诊断由 System.gc() 导致的 CPU 飙升和 GC overhead alert]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/92599235</link><guid>https://blog.youkuaiyun.com/spytian/article/details/92599235</guid><author>spytian</author><pubDate>Mon, 17 Jun 2019 12:30:20 +0800</pubDate><description><![CDATA[在六月一个炎炎烈日的周六, 我坐在凉爽的空调房里, 突然发现生产环境有个机器 CPU 一直狂转, 我想着: 这可不行, 本来地球就够热的了, 为了保护环境, 一定要把它的 CPU 降下来.

它是一个 java 应用程序, 进一步查看其它指标, 发现这货还一直报 GC overhead alert, 原来有个二货工程师写的新 bug, 一定要把它找出来.

下载 verbose GC log, 通...]]></description><category></category></item><item><title><![CDATA[多线程情况下不正确的编码引起的内存泄漏]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/90730929</link><guid>https://blog.youkuaiyun.com/spytian/article/details/90730929</guid><author>spytian</author><pubDate>Sat, 01 Jun 2019 16:51:40 +0800</pubDate><description><![CDATA[那年冬天, 新上线了一个处理在线消息的应用, 这个应用上线没多久, 就被发现有内存泄漏的问题. 从verbose GC log 来看, 是内存 heap 被用光了. 于是进一步做了一个 heap dump, 发现里面有个 ConcurrentHashMap 占用了大部分 heap 还不释放. 看上去是这个 ConcurrentHashMap 引起的问题.

这个 ConcurrentHashMap...]]></description><category></category></item><item><title><![CDATA[Java 程序中导致CPU 100%的常见原因与诊断思路]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/88385818</link><guid>https://blog.youkuaiyun.com/spytian/article/details/88385818</guid><author>spytian</author><pubDate>Sun, 10 Mar 2019 23:00:59 +0800</pubDate><description><![CDATA[原文链接

上周某团队的某个业务的新功能1%上线, 上线不到1天, 开发人员发现该流程里下游有个应用不断有服务器挂掉, 症状表现为CPU 100%, 不能处理新请求. 为了临时快速解决该问题, 同事先是做了2个 heap dump 和 2个 CPU 在某个interval的usage的截屏, 然后让开发人员关闭该新功能, 同时下游服务器被完全重启一遍. 问题得以解决.

问题虽然被临时解决, 但是...]]></description><category></category></item><item><title><![CDATA[外企 eBay 上海 招聘 高级/资深 软件工程师 Java , 大数据, 支付, 风控, Manager, Docker, DBA, 云计算]]></title><link>https://blog.youkuaiyun.com/spytian/article/details/86555262</link><guid>https://blog.youkuaiyun.com/spytian/article/details/86555262</guid><author>spytian</author><pubDate>Sat, 19 Jan 2019 18:19:50 +0800</pubDate><description><![CDATA[办公地点在张江, 弹性工作制, 很少加班, 经常去美国出差, 欢迎自荐, 推荐, 本人是内部开发人员

联系: eGlhdGlhbkBlYmF5LmNvbQ==

以下是最新(2019/01/17)的职位列表:

. 职位名称 (招聘人数 ) 部门 + 技能

MTS 1, Software Engineer-Payments ( &amp;gt;10 ) Payments Core Java, Dist...]]></description><category></category></item></channel></rss>