为什么Redis默认序列化器处理之后的key会带有乱码？-六虎

本文参加「新人创作礼」活动，一同敞开创作之路。

我的变强之路

为什么Redis默许序列化器处理之后的key会带有乱码？

主张翻开代码跟着看

1、直接从yml装备中进入redis装备文件：

2、看下哪些文件用到了RedisProperties

发现只要一个类引证到了

3、进到RedisAutoConfiguration类

发现也是个主动装备的类，并且内部包含一个主动装备的静态内部类RedisConfiguration

能够看到这儿界说了RedisTemplate的bean，并初始化了RedisTemplate的ConnectionFactory特点

4、进入RedisTemplate

发现RedisTemplate承继了RedisAccessor并完成了两个接口先搜一下内部有没有静态代码块

发现是没有的，那么看看它的父类（Java是强承继的）

5、RedisTemplate父类：RedisAccessor

好，要害来了 RedisAccessor完成了一个接口：InitializingBean

接口中只界说了一个办法：afterPropertiesSet(); 这个办法会在所有bean特点赋值之后被BeanFactory调用（注释翻译，具体为什么，后续看完springboot主动装备和bean的生命周期相关源码之后再补充）

6、那么回到RedisTemplate的父类RedisAccessor看看它里边的afterPropertiesSet()办法里做了些什么

界说了一个断语，用来判别RedisConnectionFactory是否被界说了

7、再回到RedisTemplate看看它里边的afterPropertiesSet()办法里做了些什么

public class RedisTemplate<K, V> extends RedisAccessor implements RedisOperations<K, V>, BeanClassLoaderAware {
	private boolean enableTransactionSupport = false;
	private boolean exposeConnection = false;
	private boolean initialized = false;
	private boolean enableDefaultSerializer = true;
	private RedisSerializer<?> defaultSerializer;
	private ClassLoader classLoader;
	/**以下几种序列化器都被界说为null*/
	private RedisSerializer keySerializer = null;
	private RedisSerializer valueSerializer = null;
	private RedisSerializer hashKeySerializer = null;
	private RedisSerializer hashValueSerializer = null;
	private RedisSerializer<String> stringSerializer = new StringRedisSerializer();
	private ScriptExecutor<K> scriptExecutor;
	// cache singleton objects (where possible)
	private ValueOperations<K, V> valueOps;
	private ListOperations<K, V> listOps;
	private SetOperations<K, V> setOps;
	private ZSetOperations<K, V> zSetOps;
	private GeoOperations<K, V> geoOps;
	private HyperLogLogOperations<K, V> hllOps;
	/**
	 * Constructs a new <code>RedisTemplate</code> instance.
	 */
	public RedisTemplate() {}
	public void afterPropertiesSet() {
		super.afterPropertiesSet();
		boolean defaultUsed = false;
		if (defaultSerializer == null) {
			/**这儿便是默许序列化器的界说了*/
			defaultSerializer = new JdkSerializationRedisSerializer(
					classLoader != null ? classLoader : this.getClass().getClassLoader());
		}
		/**enableDefaultSerializer默许为true*/
		if (enableDefaultSerializer) {
			/**
			*对keySerializer 、
			* valueSerializer、
			* hashKeySerializer、
			* hashValueSerializer 赋值
			*/
			if (keySerializer == null) {
				keySerializer = defaultSerializer;
				defaultUsed = true;
			}
			if (valueSerializer == null) {
				valueSerializer = defaultSerializer;
				defaultUsed = true;
			}
			if (hashKeySerializer == null) {
				hashKeySerializer = defaultSerializer;
				defaultUsed = true;
			}
			if (hashValueSerializer == null) {
				hashValueSerializer = defaultSerializer;
				defaultUsed = true;
			}
		}
		if (enableDefaultSerializer && defaultUsed) {
			Assert.notNull(defaultSerializer, "default serializer null and not all serializers initialized");
		}
		if (scriptExecutor == null) {
			this.scriptExecutor = new DefaultScriptExecutor<K>(this);
		}
		initialized = true;
	}

==从代码中能够看到如果没有修正redis默许序列化器，那么redis的默许序列化器便是用当时类加载器为参数界说的一个JdkSerializationRedisSerializer目标，并且其中的keySerializer、valueSerializer、hashKeySerializer、hashValueSerializer四种序列化器都默许和defaultSerializer相同！==

8、接着进到JdkSerializationRedisSerializer

从界说默许序列化器那行代码进到的办法先看一下SerializingConverter是个什么：

Serializer是什么现已再了解不过了吧，那么看看结构办法中的DefaultSerializer又是什么：

DefaultSerializer完成了jdk的Serializer接口并完成了里边的serialize办法，这个当地便是key最后被处理的当地。

9、以上便是redis默许序列化器的进程，上面说到一个类加载器由于和文章标题没有太大联系就不细说了，至于作用已然有序列化肯定就有反序列化，那个类加载器便是用来反序列化的

10、redisTemplate.opsForValue().set()这个办法和了解吧，往redis里做刺进操作，看看里边是怎样对key做操作的，进到RedisTemplate完成的RedisOperations接口：

找到opsForValue()办法：

回来了一个ValueOperations目标，进到这个目标找到它的set办法：

持续看完成了set办法的类：

这儿看到只要一个DefaultValueOperations类完成了set办法，跟进去：

set办法的庐山真面目！其他的不管，看下key是怎样被处理的，这儿创立一个ValueDeserializingRedisCallback目标的时分把key传了进去，跟进去看下key有没有被做什么处理

仅仅给大局key赋值，这个时分key是ValueDeserializingRedisCallback目标的一个特点了；注意这个ValueDeserializingRedisCallback类是一个笼统类，里边的inRedis()是一个笼统办法，doInredis被final润饰那么inRedis办法是要被完成的，而doInredis办法是不允许被修正的；

11、回到set办法：

知道key被赋给ValueDeserializingRedisCallback没有被操作后，那便是execute办法里对ValueDeserializingRedisCallback这个目标进行了操作，跟进execute办法：

一向跟下来发现终究回到了RedisTemplate中的execute()办法，这个时分key是在目标action内的，找一下办法内有哪些当地用到了action这个目标：

发现只要两个当地用到了，第一个当地是一个断语，用于判别action是否为null，即没有被创立，第二个是调用了action本身的doInRedis办法，还记得这个action是哪个类里边的办法吧，有点绕的话回到第10步看一下。这个action是ValueDeserializingRedisCallback的目标，那么进到ValueDeserializingRedisCallback里边看一下其中的doInRedis()办法：

能够看到doInRedis()办法里边有一个rawKey()办法对key做了处理，跟进去：

先看一下keySerializer()是个什么：

回来一个RedisSerializer目标(Redis序列化器)，持续跟进template.getKeySerializer();

回到了RedisTemplate中的getKeySerializer()办法，回来了keySerializer，第7步中现已说到。没有指定默许序列化器的情况下keySerializer和defaultSerializer是相同的；已然keySerializer()不回来null，那么终究rawKey()办法回来的便是keySerializer().serialize(key)；

12、跟进serialize()：

这个JdkSerializationRedisSerializer了解吗？是不是便是初始化RedisTemplate的时分创立的那个序列化器？不记得的话回到第3步看一下；

13、看到这儿如同还没有阐明为什么默许序列化器处理的key为什么会带有乱码；快了，以上梳理出了key的序列化进程和默许的序列化器，那么就写个程序来调用默许序列化器处理key，看看究竟哪一步搞出了乱码：

public class RedisKeySerialize<K,V> {
    static {
        System.out.println("=============REDIS序列化KEY东西==================");
    }
    public String scan(){
        System.out.println("\n"+"* 请输入Key：");
        return new Scanner(System.in).next();
    }
	/**处理key*/
    public String handleKey(K key){
        String returnStr = "";
        final byte[] rawKey = rawKey(key);
        returnStr = new String(rawKey);
        return returnStr;
    }
	/**结构一个序列化器*/
    RedisSerializer keySerializer() {
        return new JdkSerializationRedisSerializer(this.getClass().getClassLoader());
    }
	/**序列化key*/
    public byte[] rawKey(K key){
        if (keySerializer() == null && key instanceof byte[]) {
            return (byte[]) key;
        }
        return keySerializer().serialize(key);
    }
    public static void main(String[] args) {
        RedisKeySerialize keySerialize = new RedisKeySerialize();
        while (true) {
            String key = keySerialize.scan();
            String result = keySerialize.handleKey(key);
            System.out.println("* 存于Redis的key为：");
            System.out.println(result);
        }
    }
}

执行：

现在来一步步调试：

呈现了呈现了，能够看到创立ByteArrayOutputStream流的时分还一切正常，可是到了构建ObjectOutputStream流的时分呈现了乱码！这个时分能够下个初步定论了：==运用Redis默许序列化器处理key，key的序列化进程中ByteArrayOutputStream转ObjectOutputStream时会发生乱码==

那么接下来看一下为什么ByteArrayOutputStream转ObjectOutputStream时会发生乱码：

进来ObjectOutputStream的结构办法，发现传进来的ByteArrayOutputStream被转换成了BlockDataOutputStream，那么后续操作的便是BlockDataOutputStream了即目标bout

经过debug发现直到 writeStreamHeader()办法bout中的byte数组buf中仍是都全部为0，进入writeStreamHeader()办法：

这儿对bout做了两次writeShort()操作；STREAM_MAGIC和STREAM_VERSION是两个常量，

跟进writeShort()办法：

直到Bits.putShort这一步，buf中还全部都为0 再持续看一下Bits.putShort这个办法是个什么操作：

传进来的byte[]数组的第off+1位变成val的byte值，第off位变成val右移8位的byte值！好的，持续调试看看是不是由于这个putShort把buf给修正了：

这便是为什么Redis默许序列化器处理key之后会有乱码的原因地点了。

附上抽丝剥茧之后默许序列化器的执行代码：

String key = "test";
ByteArrayOutputStream out = new ByteArrayOutputStream(1024);
ObjectOutputStream objectOutputStream = new ObjectOutputStream(out);
objectOutputStream.writeObject(key);
objectOutputStream.flush();
byte[] bytes = out.toByteArray();
String finalKey = new String(bytes);

总结：
1、redis默许序列化器：JdkSerializationRedisSerializer;
2、redis默许序列化器底层运用ByteArrayOutputStream流对key进行序列化操作;
3、序列化key的进程中ByteArrayOutputStream转为ObjectOutputStream;
4、ObjectOutputStream结构办法中将传入的输出流做了一个writeStreamHeader()操作，writeStreamHeader()调用Bits.putShort办法修正了流中本来为空的byte数组中的几位字节，导致本来为空的流有值;

就比如一个本来洁净的瓶子装的水倒出来仍是洁净的水，，但一个瓶子里本来有杂质，那么倒出来的水自然也就有杂质了。如果byte[]中的几位字节没有被修正，那么也就不会发生乱码了；

最后，如有缺乏欢迎指正。

为什么Redis默认序列化器处理之后的key会带有乱码？

为什么Redis默许序列化器处理之后的key会带有乱码？

相关文章

Java & Go 专场 | 阿里云中间件开发者线下 Meetup 开启报名

【AI】用 GPT 帮小兔子画肖像

HarmonyOS玩转ArkUI动效 – 水母动画

被约谈，两天走人，一些思考

作者信息