生产问题（十三）谷歌Protobuf误修改系统全局时区

news2024/9/27 9:30:11

一、引言

最近其他组出了个线上问题，导致用户的时间出现问题，影响用户出行，后来才发现是谷歌的Protobuf会更改系统全局时区。不过有一说一，感觉jdk的问题更大。

Protobuf（Protocol Buffers）是一种轻量级的数据序列化格式，由Google开发。它可以用于将结构化数据序列化为二进制格式，以便在不同的系统之间进行数据交换和存储。Protobuf具有高效、紧凑和可扩展的特点，可以在多种编程语言中使用。它通常用于网络通信、数据存储和配置文件等方面。

二、时区结构

一开始这个问题看的作者非常迷惑，因为报告写的是修改了机器时区，什么意思？调用了操作系统对应时区的api？不可能吧，这种代码在哪里都不会给他用的，review要被喷死，再看看。

哦，原来是jvm时区的TimeZone里面的全局变量被改了。这个不能叫做机器时区，就是个全局的时区变量。

在看问题之前先要看看时区的结构，不然不了解全局的时区变量在哪里。

1. TimeZone（时区）：TimeZone 类用于表示不同地区的时区信息。它提供了获取和设置时区偏移量、获取时区名称等方法。通过 TimeZone 类，你可以将日期和时间转换为特定时区的表示形式。

2. Calendar（日历）：Calendar 类是一个抽象类，用于处理日期和时间的计算和操作。它提供了获取和设置年、月、日、时、分、秒等日期和时间字段的方法。Calendar 类还提供了一些方便的方法，如计算两个日期之间的差异等。通过 Calendar 类，你可以执行日期和时间的各种操作。

3. GregorianCalendar（公历）：GregorianCalendar 类是 Calendar 类的一个具体实现，用于处理公历日期和时间。它继承了 Calendar 类的功能，并提供了更多的方法和功能。GregorianCalendar 类支持闰年、月份天数等公历特性。

一旦使用 TimeZone 类初始化了一个时区对象，该时区对象的偏移量和其他属性是固定的，不会随着时间的推移而变化。时区对象的属性在初始化时被确定，并且不会自动更新。
不过时区对象的属性可以通过调用 TimeZone 类的方法来进行更改。例如setRawOffset() 方法来更改时区的原始偏移量，或者通过 setDSTSavings() 方法来更改夏令时的偏移量。

三、分析-构造函数

这其实是错误的方向，想直接看Protobuf问题的可以直接跳到第四章，不过作者认为错误的方向也是有必要的，因为不管是一时的还是长期的错误方向，既然它能使经验丰富的开发人员产生错误的想法，他就一定是有价值的。

就像很多学校研究，其实不一定能研究出什么对的，但是可以排除很多的错误的方向，并且在很多方面为别人提供避雷指引。

出问题的代码

public sType() {
    this.sDate = new GregorianCalendar(1，0，1，0，0，0)；
    this.sDate.setTimeZone(ZoneInfo.getTimeZone("UTC"));
}

这是框架生成的一个构造方法，相对于在不为空的情况下给你时间一个默认值，默认值是0时区。

按道理说这样只是一个局部变量，为什么会对TimeZone的全局变量造成影响呢？只能说明在这段代码里面，把一个局部变量和全局变量做了关联，使用同一个引用，然后局部变量被修改，映射到了全局变量上面。

这里拿到timezone的全局变量

全局变量传递

这时候Calendar的局部变量与TimeZone的全局变量同一个引用

这里传入了TimeZone的全局变量，然后给到了Calendar那个局部变量

第二行setTimeZone把Calendar的局部变量改为0时区，但是这时候TimeZone的全局变量和Calendar局部变量引用相同，全局变量也被修改

这里会把局部变量的引用直接换成入参

TimeZone的这个全局变量和局部变量绑定了，所以改局部变量就会改全局变量

有的同学看着这个应该就会有想法了，因为引用关联是会有影响，但是需要修改引用的值。直接替换引用对于第一个全局变量是不产生影响的

四、分析-Protobuf

需要先写个demo，结合目前的情况，是因为类里面有个GregorianCalendar类型的字段，然后这个类被Protobuf序列化存到redis，又在其他时候被反序列化拿出来用。那么demo就很清晰了：

private static final DefaultIdStrategy ID_STRATEGY = ((DefaultIdStrategy)RuntimeEnv.ID_STRATEGY);

private static <T> byte[] serialPojoByClass(T value) {
byte[] result = null;

 Class<T> clazz = (Class<T>)value.getClass();
 Schema<T> schema = RuntimeSchema.getSchema(clazz, ID_STRATEGY);
 result = ProtobufIOUtil.toByteArray(value, schema, LinkedBuffer.allocate());

 return result;
}

public static class DateTest {
private GregorianCalendar testDate;

 public void setT(GregorianCalendar testDate) {
this.testDate = testDate;
 }
}

public static <T> T deserializePojo(byte[] bytes, Class<T> clazz)
throws IllegalAccessException, InstantiationException {

if (bytes == null || bytes.length == 0) {
return null;
 }

return deserializePojo(bytes, 0, bytes.length, clazz);
}

private static <T> T deserializePojoByClass(byte[] bytes, int offset, int length, Class<T> clazz)
throws IllegalAccessException, InstantiationException {
if (clazz.isArray()) {
return null;
 }

Schema<T> schema = RuntimeSchema.getSchema(clazz, ID_STRATEGY);
 T result = clazz.newInstance();
 ProtobufIOUtil.mergeFrom(bytes, offset, length, result, schema);
 return result;
}

public static <T> T deserializePojo(byte[] bytes, int offset, int length, Class<T> clazz)
throws InstantiationException, IllegalAccessException {

if (bytes == null || bytes.length == 0) {
return null;
 }

return deserializePojoByClass(bytes, offset, length, clazz);
}

public static void main(String[] args) throws IOException, InstantiationException, IllegalAccessException {
DateTest dateTest = new DateTest();
 GregorianCalendar t = new GregorianCalendar(1, 0, 1, 0, 0, 0);
 t.setTimeZone(ZoneInfo.getTimeZone("UTC"));
 dateTest.setT(t);
 byte[] s = serialPojoByClass(dateTest);
 System.out.println("序列化前：" + TimeZone.getDefault().getID());
 deserializePojo(s, DateTest.class);
 System.out.println("序列化后：" + TimeZone.getDefault().getID());

}

先看效果再分析，很奇怪吧，我只是序列化再反序列化，怎么全局时区被改了。