IPv6 地址处理时的小 Bug

众所周知,IPv6 地址中可以用 ::  来省略一连串的 0,于是,在某些情况下,如果 0 被过度合并了,就会导致地址解析的问题。

最近在 AWS 上启用 IPv6 的时候就遇到了这个情况,AWS 分配给我的地址段是:

2406:da14:5c9::/56

可以看出,AWS 实际给我分配的地址是:

2406:da14:5c9:0000::/56

但是由于连续 0 的省略策略,导致 5c9 之后的真正可以被划分的部分被省略了。于是在 AWS 的系统中,子网划分页面就显示成了这样:

2406:da14:5__::/64

按照正常逻辑应该是这样:

2406:da14:5c9:00__:/56

结果当然就悲剧了。这里我除了填 c9 之外,任何的值都会导致划分出的子网不在上面的地址段内,导致划分失败。

所幸的是 AWS 的系统可以随意的解绑地址段,然后重新分配。于是重新分配之后就好了。

不过这里也是对我们的一个提醒:由于 (更多…)

记一则由于整数溢出导致的教科书级的死循环

首先铺垫一下,这段代码的输出是什么?

public static void main(String []args){
    System.out.println(Integer.MAX_VALUE + 1);
}

很多人可能很快就能答出来,正确答案是:-2147483648

那么接下来看这段代码:

public static void main(String []args){
    Long total = Long.MAX_VALUE;
    for (int i = 0; i < total; i++) {
        System.out.println(i);
    }
}

乍看之下似乎没啥大毛病,但是结合前面的铺垫,就会发现:

当 i 增长到 Integer.MAX_VALUE  的时候,“奇迹”出现了。接下来,下一个 i 值变为了 -2147483648。跟 (更多…)

MyBatis 获取自增 ID 的小坑

在 MyBatis 中,获取自增 ID 主要有两个方法:

  1. 在 SQL 中增加两个属性,useGeneratedKeys  和 keyProperty
  2. 增加 selectKey  语句块,执行自定义 SQL 获取自增 ID

针对这几种方法,有几个小问题需要注意:

  1. useGeneratedKeys  是基于 JDBC 的 Prepared Statement  实现的,具体做法是调用 JDBC 的 getGeneratedKeys  方法,在 Prepared Statement  对象中取相应的值。当 DB 为 MySQL 的时候,会在响应时返回相应的自增字段值。但是,在某些实现 DB 分库分表的 Proxy 中,由于涉及 SQL 转换、重写的问题,可能对 Prepared Statement  的支持并不完整,导致 useGeneratedKeys  选项无法正常返回对应的自增 (更多…)

JVM DNS IP 地址缓存 (InetAddress)

(本文所有内容基于 Oracle JDK)

JVM IP 地址缓存

JVM 的缓存策略

由于 DNS 解析是一个访问量大的不是很可靠的网络调用,因此通常大部分系统都会对 DNS 解析的结果进行一定程度的缓存。如运营商的 LDNS、常用的浏览器、包括操作系统本身,都会对 DNS 解析的结果进行缓存。在 JVM 中,为了加速 DNS 解析的过程,当然也进行了相关的缓存。

在 Java 中,最常用的进行 DNS 解析的方法就是:

java.net.InetAddress.getAllByName(“www.google.com”);

而这个方法本身也会对解析的结果进行相应的缓存。看官方文档:

InetAddress Caching

The InetAddress class has a cache to store successful as well as unsuccessful (更多…)

ScheduledExecutorService 一个小坑

今天在排查一个线上问题是发现一个使用 ScheduledExecutorService 执行的定时任务在执行了一次以后就再也没有执行过了。于是 Dump 了内存来检查问题。

首先,搜索对应 Task 的类,发现在堆中找不到这个类的实例。可是明明已经成功执行了一次,为何没有实例?

于是再去找 ScheduledExecutorService  对应的 ScheduledThreadPoolExecutor  类,成功筛选出了用来执行定时任务的实例。在实例的 queue 中,却只看到了 6 个 Task 对象,唯独不见了这个出问题的对象。百思不得解,因为日志中这个对象的 Logger 已经打印出来了,说明至少执行了一次,为啥会从内存中消失呢?

在同事的帮助下,查阅了 API 文档,发现了这么一句话:

If any execution of the task encounters (更多…)

记一次 JNI 导致 Java fd 泄露的排查过程

前几天接到反馈,线上某机器上的服务在进行后端调用的时候失败了。查看日志是端口分配失败。通过 netstat -nulp  看到大量端口占用,用户段端口49152 到 65535 全部被占满。于是通过 awk sort 和 uniq 统计出每个进程的端口占用情况,发现某些 Java 服务占用了 2w+ 端口,于是对该服务展开分析。

首先考虑的是应用有大量 Socket 对象没有关闭释放,于是将堆 dump 出来,使用 VisualVM 加载分析。由于泄露的是 UDP 端口,于是考虑查找 Java 中 UDP socket 对应的对象 DatagramSocket 。可是一顿操作之后发现堆中并不存在该类对象,倒是找到了几个 DatagramSocketAdaptor  对象。查看了框架发现使用了 Netty 做 NIO,因此实际使用的是 NioDatagramChannel 和 DatagramSocketAdaptor (更多…)

Tomcat 在处理 Cookie 的时候的几个小坑

今天在代码中调用 HttpServletRequest  对象的 getCookies()  方法时,发现实际得到的 Cookie 数量与提交的不符。实际提交了 17 个 Cookie,但是获取到的只有 14 个。

经过排查,发现如果调用 getHeaders(“Cookie”)  方法,获取原始的 Cookie 串,是可以拿到正确的 17 个 Cookie 组成的字符串的。于是确认应该是 Tomcat 在处理 Cookie 的时候进行了过滤。

经过一番搜索,发现了这个文档:

http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html

其中,跟 Cookie 相关的参数有:

org.apache.tomcat.util.http. ServerCookie.ALLOW_EQUALS_IN_VALUE If (更多…)

MySQL 低版本对 TIMESTAMP 字段 DEFAULT 值设置的一个问题

今天在线上改表的时候,遇到了一个问题。改表完成之后,MyBatis Select 改表前插入的数据会抛异常。排查后发现是因为一个 TIMESTAMP  类型的字段值被写成了 0000-00-00 00:00:00  ,无法被转换成 java 的 java.sql.Timestamp 类型,导致出错。

但是之前在使用 MySQL 的时候一直没有遇到过这个问题,于是搜索了一下,发现了这么一个链接:

https://bugs.mysql.com/bug.php?id=68040

这里反馈了一个 MySQL 本身的 Bug,会导致 ALTER table  的时候,TIMESTAMP  类型的值没有按照预期的正确设置,而是被设置成了 0000-00-00 00:00:00  。该问题在 MySQL 5.6.11 中被修复了。官方的 Release Note 在这里:

https://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-11.html#mysqld-5-6-11-bug

Nginx 诡异 SSL_PROTOCOL_ERROR 问题排查

这两天在检查一台 Nginx 配置的时候,遇到了一个极端诡异的问题。一段很通用的配置,配在这个服务器上,就会 100% 导致 Chrome 报 ERR_SSL_PROTOCOL_ERROR 。但是这段配置非常的通用,是用 Mozilla 提供的工具生成的。

而且在 iPhone 的 Safari 上访问又是完全正常的,服务器日志也看不到任何错误。看到的请求相应码也是完全正确的 200 。

先贴出配置:

# https://mozilla.github.io/server-side-tls/ssl-config-generator/
    listen 443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate (更多…)

常见 NAT 类型描述对应关系

在不同的设备上,对于各种类型的 NAT 有各自不同的描述。先列举一下目前遇到的说法:

PS4

NAT类型 显示PS4™与互联网的连接方式
使用游戏的通信功能等时,可确认与其它PS4™间的连接稳定性。
Type 1:与互联网直接连接。
Type 2:通过路由器与互联网连接。
Type 3:通过路由器与互联网连接。
显示Type 3时,可能会出现无法与其它PS4™顺利通信,使PS4™的网络功能受到限制的情形。详细请参阅

XBox

OPEN NAT MODERATE NAT STRICT NAT
With an OPEN NAT type, you’re able to chat with other people, as well as join and host multiplayer games with people (更多…)