LogbackMDC 2022年有变动？

绝地灬酷狼 2023-10-03 21:11 44阅读 0赞

今天本来在研究 线程传递参数的方式，ThreadLocal MDC，来一篇吧。。

![format_png][]

## MDC 是每个线程 都有一个么？ ##

是的，百度一下 都知道，但是 怎么证明？ 首先

MDC.put  -》 
    mdcAdapter.put(key, val);   -》 
    
    MDCAdapter 实现类 LogbackMDCAdapter 
    
    复制代码

![format_png 1][]

![format_png 2][]

## 上面第50行 可以看到 他获取之前最后一次的 标识，可以没有么？它起到了什么作用？ ##

//这里 它传入的是 1
    private Integer getAndSetLastOperation(int op) {
        Integer lastOp = (Integer)this.lastOperation.get();
        this.lastOperation.set(op);
        return lastOp;
    }
    复制代码

外面

public void put(String key, String val) throws IllegalArgumentException {
        if (key == null) {
            throw new IllegalArgumentException("key cannot be null");
        } else {
            Map<String, String> oldMap = (Map)this.copyOnThreadLocal.get();
            //设置为 1，并且 返回原来的旧值 代表着上次是什么操作
            Integer lastOp = this.getAndSetLastOperation(1);
            //上次是写操作 并且oldMap 不是null 就在oldMap 基础 上put
            if (!this.wasLastOpReadOrNull(lastOp) && oldMap != null) {
                oldMap.put(key, val);
            } else {
                Map<String, String> newMap = this.duplicateAndInsertNewMap(oldMap);
                newMap.put(key, val);
            }
    
        }
    }
    
    //需要返回 false 才代表 之前有oldMap 操作，这里的判断 不是null 不是2，看了一遍代码 这不就是1么
    private boolean wasLastOpReadOrNull(Integer lastOp) {
        return lastOp == null || lastOp == 2;
    }
    复制代码

这就需要去看看 什么时候 会lastOp 为2

![format_png 3][]

如果是 2就是上次操作是 **读**呢，这个时候 有put 操作 就 新创建一个空的newMap 赋值，如果原来是 1 代表这个线程 上次就是 **put** ，在原来的oldMap 基础上 进行put。

### 上面这个看完 会不会有一个疑问，那我多次 put （a,b 属性）然后 get下，在put a属性，难道我get b就没有了？ ###

![format_png 4][]

返回 a 和 b

一debug ,调用的是另一个获取方法，那什么时候 调用这个赋值为2的方法呢？

![format_png 5][]

接口中没有这个方法，留个疑问 继续往下

![format_png 6][]

## Thread 和 ThreadLocal的关系 是一对一么？ ##

上面说到 Thread 中有 ThreadLocal.ThreadLocalMap

![format_png 7][]

## 变化 ##

上面的东西 看完，感觉应该结尾了吧。。。NO， 2022年这个put 方法有变化了。。。。

![format_png 8][]

往下继续看 注释 fix LOGBACK-1684 using code from LOGBACK-620

既然你这么说了 我就分别看看 这两个

[jira.qos.ch/browse/LOGB…][jira.qos.ch_browse_LOGB]

代码改动在 [github.com/qos-ch/logb…][github.com_qos-ch_logb]

### 为什么改动呢 保持原版不香么 ###

大概意思 在对我们的应用程序进行性能分析时，LogbackMDCAdapter**显示为性能热点**。这是因为应用程序确实经常替换MDC中的多个条目，例如 删除/写入而不使用任何中间日志语句。另外，在生产环境中，在创建LoggingEvent之前经过过滤的实际日志消息相对较少。我重做了实现，以提高性能。其主要思想是尽可能推迟克隆内部Map。该补丁在该测试中提高了应用程序的总体性能约10%

![format_png 9][]

里面 为了替换原来的 flag 判断，现在多了

final ThreadLocal<Map<String, String>> readWriteThreadLocalMap = new ThreadLocal<Map<String, String>>();
    final ThreadLocal<Map<String, String>> readOnlyThreadLocalMap = new ThreadLocal<Map<String, String>>();
    复制代码

### 讨论 ###

下面评论区 Ceki 大佬提出，你现在 用了2个对象，是不是可以通过

Get操作从来不需要复制或连续的“put/remove”操作，只有Get后面跟着“put/remove”操作需要复制map

这样就可以 so on Note that 8 operations were performed by only 3 maps were created

但是 Michael 大佬说

但作为一名软件开发人员，我对你的策略感到有点不舒服:“读后写后复制”听起来与“写后复制”和“惰性复制”不太一样。使用您的方法，您将迫使开发人员关注放置和获取操作的顺序，特别是如果应用程序在写入MDC之前执行存在性检查。

![format_png 10][]

Ceki 大佬 最后说 经过测试 你写的确实不错 哈哈

![format_png 11][]

### 彩蛋 ###

版本升级后

//这个方法 原来是 赋值为2的，现在修改了
    public Map<String, String> getPropertyMap() {
        Map<String, String> readOnlyMap = readOnlyThreadLocalMap.get();
        if (readOnlyMap == null) {
            Map<String, String> current = readWriteThreadLocalMap.get();
            if (current != null) {
                final Map<String, String> tempMap = new HashMap<String, String>(current);
                readOnlyMap = Collections.unmodifiableMap(tempMap);
                readOnlyThreadLocalMap.set(readOnlyMap);
            }
        }
        return readOnlyMap;
    }
    复制代码

像不像 Eureka 的多级缓存机制，都一个道理

里面一个点 是 使用了 Collections.unmodifiableMap，所有对外返回的list map等引用参数，都要重新赋值一遍 / 只读不能操作。防止 外部改变这个元素 影响我们。

**不可变类** 也是一个道理，返回需要 重新生成一个，不会直接返回 原来的元素，不可变类 防止的是 一个对象中有20个属性， 防止20个属性出现中间态，比如 5个属性 属于v1， 15个属性 属于v2 这种中间态情况。

[format_png]: https://img-blog.csdnimg.cn/img_convert/bf9d80955f790d36cd19e62528df4f1c.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/a314d1d3bb063424462daf6ba7bcb867.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/44f7acb71e8cbaafdd088e051c91a80c.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/e9593c57749f63b6484789a28b934517.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/85ed0e21bad67e531f7e3db5debd35a9.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/78a0aaf670c1cd556c3c3937b3bf5d42.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/44db2d7b0cf21c8a154bb4c003a22040.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/b9e6f1955ebf5d1c0d5ed947f534b5d7.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/fbd21b2b89dac433aef050e11514336a.webp?x-oss-process=image/format,png
[jira.qos.ch_browse_LOGB]: https://link.juejin.cn/?target=https%3A%2F%2Fjira.qos.ch%2Fbrowse%2FLOGBACK-620
[github.com_qos-ch_logb]: https://link.juejin.cn/?target=https%3A%2F%2Fgithub.com%2Fqos-ch%2Flogback%2Fcommit%2F7e3e2ae770c19
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/279b313cef6bb951ea1bca17940a4462.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/28fa8ec3e91a8238528cf3ba376017f8.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/4ed3c912d6f703e56a3426246a38580d.webp?x-oss-process=image/format,png