一、背景

最近在看代码，发现一个 Date 格式化为 String 的方法。

1
2
3

public String dateFormatString() {
    return new SimpleDateFormat("yyyy-MM-dd HH:mm:ss.SSS").format(date);
}

看到这个方法想到

• 每次都 new 一个 format 会快么(非线程安全，得每次都 new)？
• SimpleDateFormat 格式化快么？
• “yyyy-MM-dd HH:mm:ss.SSS” 改成静态常量会不会快点？

带着以上三个疑问，就想着做个对比测试。
恰巧最近在 perfma 社区看 jvm 相关内容时，刷到了『性能调优必备利器之 JMH』
于是乎就有了下面的内容

二、结论

性能从低到高

• java.text.SimpleDateFormat
• org.apache.commons.lang.time.DateFormatUtils
• org.joda.time.DateTime

字符串静态常量影响

• 是否静态常量几乎没有影响
• 使用常量反而性能有所下降(???为何)

1
2
3
4
5
6

Benchmark                                             Mode  Cnt        Score        Error  Units
DateConvertTest.dateFormatString                     thrpt   10   867333.631 ±   9510.553  ops/s
DateConvertTest.dateFormatStringApache               thrpt   10  2158217.955 ±  89012.866  ops/s
DateConvertTest.dateFormatStringApacheStaticPattern  thrpt   10  2141167.550 ±  93715.889  ops/s
DateConvertTest.dateFormatStringJoda                 thrpt   10  2802803.925 ± 121600.833  ops/s
DateConvertTest.dateFormatStringJodaStaticPattern    thrpt   10  2744918.391 ± 131925.235  ops/s

说明：
Error 列是空的，看 Score 和 Units 即可
ops/s:一秒钟执行多少次操作

三、代码

3.1 引入相关 jar

1
2
3
4
5
6
7
8
9
10

<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-core</artifactId>
    <version>1.23</version>
</dependency>
<dependency>
    <groupId>org.openjdk.jmh</groupId>
    <artifactId>jmh-generator-annprocess</artifactId>
    <version>1.23</version>
</dependency>

3.2 IDEA 安装 JMH 插件

插件中心搜索：JMH
安装量最高的那个就是

3.3 编写代码

一、结论

JDK8 因未指定 MetaSpace 大小，程序启动过程中元空间不够用，触发 full gc。

详细如下：
JDK8 因未指定 MetaSpace 大小，默认初始大小约 21M
程序启动，元空间大小占用稳定在 90M
因为超过了默认元空间大小，导致元空间扩容(每次扩容会 full gc)
从 GC 日志来看，每次元空间扩容都是增加 20M 左右，所以程序启动时 full gc 4 次

二、问题

应用启动时出现 full gc;

gc日志重点：GC (Metadata GC Threshold) [PSYoungGen: 354024K->15340K(1376256K)

三、排查过程

待补充

一、中断的解释

网络

中断（Interrupt）是指 处理器接收到来自硬件或软件的信号，提示发生了某个事件，应该被注意，这种情况就称为中断。

软中断 (form 《UNIX 操作系统设计》)

内核在收到软中断信号的进程上下文中处理软中断信号，因此进程必须运行以便处理信号。
处理软中断信号的方式：

1. 进程忽略软中断信号;
2. 进程收到软中断信号后退出;
3. 进程收到信号后执行一个特殊的(用户)函数;

二、Java 的中断

Java API 中线程相关的方法主要有三个：

零、背景

在近两年高并发系统 DevOps 的过程中，
遇到了很多底层的问你题，eg: 网络、硬件、虚拟机等，
有些现象虽然知其然，但是不知其所以然，书到用时方恨少！
抱着深入学习的心态这两年看了一些相关书籍：

《计算机网络：自顶向下方法》
《操作系统精髓与设计原理》
《Java性能优化权威指南》
《Redis运维与开发》
《性能之巅》

收获甚大 所以想继续深入学习
误打误撞，看到了之前在 GitHub 关注的一个『自学计算机科学』仓库，很赞同下面这个观点

软件工程师分为两种：

1. 一种充分理解了计算机科学，从而有能力应对充满挑战的创造性工作；
2. 另一种仅仅凭着对一些高级工具的熟悉而勉强应付。

这两种人都自称软件工程师，都能在职业生涯早期挣到差不多的工资。
然而，随着时间流逝，第一种工程师不断成长，所做的事情将会越来越有意义且更为高薪，
不论是有价值的商业工作、突破性的开源项目、技术上的领导力或者高质量的个人贡献。

一、资源

1.1 摘要

零、摘要

响应国家就地过年的号召，今年第一次在外过年。
弹指一挥间，12 天的假期已经成为过去。
期间还是有不少的收获，最主要的是看了 4 本书。
以及在微博上面看到了不少的人和事，甚是触动。

找到自己的兴趣，追求精进，坚持做对的事情。

一、阅读

1.1 《 UML 和模式应用》0113~0207

这本书是 leader 推荐给大家的
基于职责去做设计的理念确实很棒，值得观摩实践。

零、背景

本文灵感来自《人人都是产品经理 2.0》
位置：7.4.2 如何做一个让 Ta 们讨厌的人

作为一个研发，工作过程中如果能及时发现如下场景，
及时给对方负反馈，否则受伤的是整个团队。
看了这本书之后，感觉对产品有新的认知，
知道他们在做什么，怎么做，后续可以更好的与他们沟通。
而且里面的内容对于研发来讲也是适用的。

一、开始实施之前

1.1 不说清需求价值

技术问”为什么要做”时：
1、时支支吾吾
2、这是老板(XXX)要的，假装自己是个传话筒
3、我接的是二手需求，什么都不知道
随说：其实正确的做法是追溯这个需求的初衷，有利于评估 ROI (投入产出比)，以及排优先级，以及增进对业务的理解。

1.2 不去想细节功能

一、背景

由于某种原因，需要手工处理错误日志提取某些信息。
下载下来的日志文件是压缩包

1.1 文件信息

1
2
3
4

system_error.log.2020-11-01.20201105200433.zip
system_error.log.2020-11-01.20201105195953.zip
system_error.log.2020-11-01.20201105200830.zip
...省略

1.2 压缩包信息

1
2
3
4
5
6
7

$ unzip -v system_error.log.2020-11-01.20201105200830.zip
Archive:  system_error.log.2020-11-01.20201105200830.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
 4495560  Defl:N    78526  98% 11-01-2020 23:43 504551c6  system_error.log.2020-11-01
--------          -------  ---                            -------
 4495560            78526  98%                            1 file

压缩包文件名不一样，但是压缩包中的文件有一样的名字。
例如：system_error.log.2020-11-01

尝试使用如下方式，提示有重复，需要挨个选择如何处理，极度不便。
于是想使用 shell 来解决（ 之前没写过 shell ）

1.2 尝试过程

一、常见单位

进制除了 Byte 与 bit 之间是 8，其它的都是 1024，但是目前很多时候习惯用 1000，比如 1T ≈ 1000G;

二、带宽/网速

2.1 带宽

运营商(ISP)带宽宣传常见的有：50M、100M、500M、1000M…
注意：这是传输速率，而不是下载速度。

零、背景

最近做压力测试，不同的系统的机器监控数据差异明显
A 系统：CPU 高 load 低
B 系统：CPU 低 load 高

那么是什么导致 A B 系统出现这种情况？
CPU 高了系统肯定跑不动了，那么 load 多高代表系统跑不动呢？

一、解释

1. A 系统的原因
   CPU 很忙，没有等待其它资源，瓶颈在 CPU。
2. B 系统的原因
   等待磁盘 I/O 完成的进程过多，导致进程队列长度过大，
   但是 CPU 运行的进程却很少，这样就导致负载过大，但 CPU 使用率低，瓶颈不在 CPU，可能在 I/O。

二、load averages 知识

1. Linux 系统下代表的是 system load averages。

2. Linux load averages track not just runnable tasks, but also tasks in the uninterruptible sleep state.
   Linux 平均负载不仅跟踪可运行的任务，还跟踪处于不可中断睡眠状态的任务。

3. On Linux, load averages are (or try to be) “system load averages”, for the system as a whole, measuring the number of threads that are working and waiting to work (CPU, disk, uninterruptible locks). Put differently, it measures the number of threads that aren’t completely idle. Advantage: includes demand for different resources.
   在 Linux 上，负载平均值是(或试图是)“系统负载平均值” ，对于整个系统来说，测量正在工作和等待工作的线程数(CPU、磁盘、不可中断锁)。换句话说，它测量的是没有完全空闲的线程数量。优势: 包括对不同资源的需求。

4. In 1993, a Linux engineer found a nonintuitive case with load averages, and with a three-line patch changed them forever from “CPU load averages” to what one might call “system load averages.” His change included tasks in the uninterruptible state, so that load averages reflected demand for disk resources and not just CPUs.
   1993年，一位 Linux 工程师发现了一个与平均负载不直观的案例，一个三行补丁永远地将它们从“ CPU 负载平均值”改变为人们可能称之为“系统负载平均值”他的更改包括处于不可中断状态的任务，因此平均负载反映了对磁盘资源的需求，而不仅仅是 cpu。

三、总结

1. linux load averages 数字大，代表系统压力大;
   阅读全文 »

零、背景说明

目前测试机器为 4C8G
两台机器完全处理一样的工作
大部分时间对象朝生夕死，很少进入老年代
CMS 指定了新生代最大 1536M，略微有点浪费
于是设置 G1 自动调节各个区域大小，看看能否有所改善
也因为最近重温了两本 JVM 相关的书籍，找机会进行实践看看

一、G1 设置

1
2
3
4
5
6
7
8
9
10
11
12
13
14

-Xms4096M
-Xmx4096M
-XX:+UseG1GC
-XX:+UnlockDiagnosticVMOptions
-XX:SurvivorRatio=8
-XX:+ParallelRefProcEnabled
-XX:MaxTenuringThreshold=6
-XX:ParGCCardsPerStrideChunk=4096
-XX:MaxGCPauseMillis=100
-XX:MaxMetaspaceSize=256M
-XX:MetaspaceSize=256M
-XX:+PrintGCDateStamps
-XX:+PrintGCDetails
-Xloggc:/home/hisen/gc.log

二、CMS 设置