毫秒时间位数，时而1位，时而2位，时而3位，搞得我好乱呐！

Posted on by hackdl

开心一刻

　　今天我突然顿悟了，然后跟我妈聊天

　　我：妈，我发现一个饿不死的办法

　　妈：什么办法

　　我：我先养个狗，再养个鸡

　　妈：然后了

　　我：我拉的狗吃，狗拉的鸡吃，鸡下的蛋我吃，如此反复，我们三都饿不死

　　妈：你整那么多中间商干啥，你就自己拉的自己吃得了，还省事

　　我又顿悟了，回到：也是啊

　　说句很重要的心里话：祝大家在2024年，身体健康，万事如意！

场景重温

　　为了让大家更好的明白问题，先做下相关准备工作

　　环境准备

　　数据库：MySQL 8.0.30，表：tbl_order

DROP TABLE IF EXISTS `tbl_order`;
CREATE TABLE `tbl_order`  (
  `id` bigint(0) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增主键',
  `order_no` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '业务名',
  `created_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) COMMENT '创建时间',
  `updated_at` datetime(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3) COMMENT '最终修改时间',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 3 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci COMMENT = '订单' ROW_FORMAT = Dynamic;

-- ----------------------------
-- Records of tbl_order
-- ----------------------------
INSERT INTO `tbl_order` VALUES (1, '123456', '2023-04-20 07:37:34.000', '2023-04-20 07:37:34.720');
INSERT INTO `tbl_order` VALUES (2, '654321', '2023-04-20 07:37:34.020', '2023-04-20 07:37:34.727');

View Code

　　基于JDK1.8、druid 1.1.12、mysql-connector-java 8.0.21、Spring 5.2.3.RELEASE

　　完整代码：druid-timeout

　　毫秒位数捉摸不透

　　直接运行com.qsl.DruidTimeoutTest#main，会看到如下结果

　　数据库表中的值：2023-04-20 07:37:34.000运行出来后是2023-04-20 07:37:34.0，2023-04-20 07:37:34.720对应2023-04-20 07:37:34.72

　　2023-04-20 07:37:34.020对应2023-04-20 07:37:34.02，2023-04-20 07:37:34.727对应2023-04-20 07:37:34.727

　　毫秒位数时而1位，时而2位，时而3位，搞的我好乱呐

原因分析

　　大家注意看这个代码

　　获取列值，sqlRowSet.getObject(i)返回的类型是Object，我们调整下输出：System.out.println(obj.getClass().getName() + ” ” + obj);

　　此时输出结果如下

　　可以看到，java程序中，此时的时间类型是java.sql.Timestamp

　　有了这个依托点，原因就很好分析了

　　Timestamp的toString

　　我们知道，java中直接输出对象，会调用对象的toString方法，如果自身没有重写toString则会沿用Object的toString方法

　　我们先来看一下Object的toString方法

　　粗略看一下，返回值明显不是2023-04-20 07:37:34.0这种时间字符串格式

　　那说明什么？

　　说明Timestamp肯定重写了toString方法嘛

　　java.sql.Timestamp#toString内容如下

/**
 * Formats a timestamp in JDBC timestamp escape format.
 *         yyyy-mm-dd hh:mm:ss.fffffffff,
 * where ffffffffff indicates nanoseconds.
 * 

 * 
@return a String object in
 *           yyyy-mm-dd hh:mm:ss.fffffffff format
 */
@SuppressWarnings("deprecation")
public String toString () {

    int year = super.getYear() + 1900;
    int month = super.getMonth() + 1;
    int day = super.getDate();
    int hour = super.getHours();
    int minute = super.getMinutes();
    int second = super.getSeconds();
    String yearString;
    String monthString;
    String dayString;
    String hourString;
    String minuteString;
    String secondString;
    String nanosString;
    String zeros = "000000000";
    String yearZeros = "0000";
    StringBuffer timestampBuf;

    if (year ) {
        // Add leading zeros
        yearString = "" + year;
        yearString = yearZeros.substring(0, (4-yearString.length())) +
            yearString;
    } else {
        yearString = "" + year;
    }
    if (month ) {
        monthString = "0" + month;
    } else {
        monthString = Integer.toString(month);
    }
    if (day ) {
        dayString = "0" + day;
    } else {
        dayString = Integer.toString(day);
    }
    if (hour ) {
        hourStr服务器托管网ing = "0" + hour;
    } else {
        hourString = Integer.toString(hour);
    }
    if (minute ) {
        minuteString = "0" + minute;
    } else {
        minuteString = Integer.toString(minute);
    }
    if (second ) {
        secondString = "0" + second;
    } else {
        secondString = Integer.toString(second);
    }
    if (nanos == 0) {
        nanosString = "0";
    } else {
        nanosString = Integer.toString(nanos);

        // Add leading zeros
        nanosString = zeros.substring(0, (9-nanosString.length())) +
            nanosString;

        // Truncate trailing zeros
        char[] nanosChar = new char[nanosString.length()];
        nanosString.getChars(0, nanosString.length(), nanosChar, 0);
        int truncIndex = 8;
        while (nanosChar[truncIndex] == '0') {
            truncIndex--;
        }

        nanosString = new String(nanosChar, 0, truncIndex + 1);
    }

    // do a string buffer here instead.
    timestampBuf = new StringBuffer(20+nanosString.length());
    timestampBuf.append(yearString);
    timestampBuf.append("-");
    timestampBuf.append(monthString);
    timestampBuf.append("-");
    timestampBuf.append(dayString);
    timestampBuf.append(" ");
    timestampBuf.append(hourString);
    timestampBuf.append(":");
    timestampBuf.append(minuteString);
    timestampBuf.append(":");
    timestampBuf.append(secondString);
    timestampBuf.append(".");
    timestampBuf.append(nanosString);

    return (timestampBuf.toString());
}

View Code

　　注意看注释：yyyy-mm-dd hh:mm:ss.fffffffff，说明精度是到纳秒级别，不只是到毫秒哦！

　　该方法很长，我们只需要关注fffffffff的处理，也就是如下代码

　　nanos类型是int：private int nanos;，用来存储秒后面的那部分值

　　数据库表中的值：2023-04-20 07:37:34.000对应的nanos的值是 0，2023-04-20 07:37:34.720对应的nanos的值是多少了？

　　不是、不是、不是720，因为它的格式是fffffffff，所以应该是720000000

　　那2023-04-20 07:37:34.020对应的nanos的值又是多少？

　　不是、不是、不是200000000，而是20000000，因为nanos是int类型，不能以0开头

　　再回到上述代码，当nanos等于 0 时，nanosString即为字符串0，所以2023-04-20 07:37:34.000对应2023-04-20 07:37:34.0

　　当nanos不等于 0 时

　　1、先将nanos转换成字符串nanosString，nanosString的位数与nanos一致

　　2、nanosString前补0，nanos的位数与 9 差多少就前补多少个0

　　　　例如2023-04-20 07:37:34.020对应的nanos是20000000，只有8位，前补1个0，则nanosString的值是020000000

　　3、去掉末尾的0

　　　　020000000去掉末尾的0，得到02

　　原因是不是找到了？

　　总结下就是：java.sql.Timestamp#toString会格式化掉nanosString末尾的0！（注意：nanos的值是没有变的）

　　是不是很精辟

　　但是问题又来了：为什么要格式化末尾的0？

　　说实话，我没有找到一个确切的、准确的说明

　　只是自己给自己编造了一个勉强的理由：简洁化，提高可读性

　　去掉nanosString末尾的 0，并没有影响时间值的准确性，但是可以简化整个字符串，末尾跟着一串0，可读性会降低

　　如果非要保留末尾的0，可以自定义格式化方法，想保留几个0就保留几个0

　　类型对应

　　MySQL类型和JAVA类型是如何对应的，是不是很想知道这个问题？

　　那就安排起来，如何寻找了？

　　别慌，我有葵花宝典：杂谈篇之我是怎么读源码的，授人以渔

　　为了节约时间，我就不带你们一步一步debug了，直接带你们来到关键点com.mysql.cj.protocol.a.ColumnDefinitionReader#read

　　里面有如下关键代码

　　为了方便你们跟源码，我服务器托管网把此刻的堆栈信息贴一下

　　我们继续跟进unpackField，会发现里面有这样一行代码

　　恭喜你，只差临门一脚了

　　按住ctrl键，鼠标左击MysqlType，欢迎来到类型对应世界：com.mysql.cj.MysqlType

　　其构造方法

　　我们暂时只需要关注：mysqlTypeName、jdbcType和javaClass

　　接下来我们找到MySQL的DATETIME

　　此处的Timestamp.class就是java.sql.Timestamp

　　其他的对应关系，大家也可以看看，比如

额外拓展

　　TIMESTAMP范围

　　回答这个问题的时候，一定要说明前提条件

　　MySQL8，范围是‘1970-01-01 00:00:01’ UTC to ‘2038-01-19 03:14:07’ UTC

　　JDK8，Timestamp构造方法

　　入参是long类型，其最大值是9223372036854775807，1 年是365*24*60*60*1000=31536000000毫秒

　　也就是long最大可以记录6269161692年，所以范围是1970 ~ (1970 + 6269161692)，不会有2038年问题

　　MySQL的TIMESTAMP和JAVA的Timestamp是对应关系，并不是对等关系，大家别搞混了

　　关于不允许使用java.sql.Timestamp

　　阿里巴巴的开发手册中明确指出不能用：java.sql.Timestamp

　　为什么mysql-connector-java还要用它？

　　可以从以下几点来分析

　　1、java.sql.Timestamp存在有存在的道理，它有它的优势

　　　　1.1 精度到了纳秒级别

　　　　1.2被设计为与SQL TIMESTAMP类型兼容，这意味着在数据库交互中，使用Timestamp可以减少数据类型转换的问题，提高数据的一致性和准确性

　　　　1.3 时间方面的计算非常方便

　　2、在某些特定情况下才会触发Timestamp的bug，我们不能以此就完全否定Timestamp吧

　　　　况且JDK9也修复了

　　3、MySQL的TIMESTAMP如果不对应java.sql.Timestamp，那该对应JAVA的哪个类型？

　　MySQL的DATETIME为什么也对应java.sql.Timestamp

　　MySQL的TIMESTAMP对应java.sql.Timestamp，对此我相信大家都没有疑问

　　为何MySQL的DATETIME也对应java.sql.Timestamp?

　　我反问一句，不对应java.sql.Timestamp对应哪个？

　　LocalDateTime？试问JDK8之前有LocalDateTime吗？

　　不过mysql-connector-java还是做了调整，我们来看下

　　我把mysql-connector-java的源码clone下来了，更方便我们查看提交记录

　　找到com.mysql.cj.MysqlType#DATETIME，在其前面空白处右击

　　鼠标左击Annotate with Git Blame，会看到每一行的最新修改提交记录

　　我们继续左击DATETIME的最新修改提交记录

　　可以看到详细的提交信息

　　双击MysqlType.java，可以看到修改内容

　　可以看到MySQL的DATETIME对应的JAVA类型从java.sql.Timestamp调整成了java.time.LocalDateTime

　　那mysql-connector-java哪个版本开始生效的了？

　　它是开源的，那就直接在github上找mysql-connector-java的issue：Bug#102321

　　但是你会发现搜不到

　　这是因为mysql-connector-java调整成了mysql-connector-j，相关issue没有整合

　　那么我们就换个方式搜，就像这样

　　回车，结果如下

　　也没有搜到！！！

　　但你去点一下左侧的Commits，你会发现有结果！！！

　　Commits不是 0 吗，怎么有结果，谁来都懵呀

　　这绝对是github的Bug呀（这个我回头找下官方确认下，不深究！）

　　我们点击Commits的这个搜索结果，会来到如下界面

　　答案已经揭晓

　　从8.0.24开始，MySQL的DATETIME对应的JAVA类型从java.sql.Timestamp调整成java.time.LocalDateTime

总结

　　java.sql.Timestamp

　　1、设计初衷就是为了对应SQL TIMESTAMP，所以不管是MySQL还是其他数据库，其TIMESTAMP对应的JAVA类型都是java.sql.Timestamp

　　2、MySQL的TIMESTAMP有2038年问题，是因为它的底层存储是 4 个字节，并且最高位是符号位，至于其他类型的数据库是否有该问题，得看具体实现

　　3、在清楚使用情况的前提下（不触发JDK8 BUG）是可以使用的，有些场景使用java.sql.Timestamp确实更方便

　　DATETIME对应类型

　　SQL DATETIME对应的JAVA类型，没有统一标准，需要看具体数据库的jdbc版本

　　比如mysql-connector-java，8.0.24之前，DATETIME对应的JAVA类型是java.sql.Timestamp，而8.0.24及之后，对应的是java.time.LocalDateTime

　　至于其他数据库的jdbc是如何对应的，就交给你们了，可以从最新版本着手去分析

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net

相关推荐: 【Java】SPI在Java中的实现与应用

一、SPI的概念 1.1、什么是API？ API在我们日常开发工作中是比较直观可以看到的，比如在 Spring 项目中，我们通常习惯在写 service 层代码前，添加一个接口层，对于 service 的调用一般也都是基于接口操作，通过依赖注入，可以使用接口实…

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用

服务器托管

咨询：董先生

电话13051898268 QQ/微信93663045！

上一篇:
下一篇: