[docs update]并发相关内容补充

[1020325258]

并发相关内容：
1、关于 synchronized 相关内容较少，补充其中偏向锁被废弃原因
2、ThreadLocal 的内存泄漏解释的比较含糊，而且这块内容比较容易被误解，增加了对内存泄漏发生情况的说明

[Snailclimb]

并发相关内容： 1、关于 synchronized 相关内容较少，补充其中偏向锁被废弃原因 2、ThreadLocal 的内存泄漏解释的比较含糊，而且这块内容比较容易被误解，增加了对内存泄漏发生情况的说明

发生内存泄漏的关键在于 ThreadLocal 对象不再被外部强引用，以及 线程持续存活。 你提到的 "ThreadLocal 被定义为方法的局部变量" 只是其中一种情况。

[Snailclimb]

并发相关内容： 1、关于 synchronized 相关内容较少，补充其中偏向锁被废弃原因 2、ThreadLocal 的内存泄漏解释的比较含糊，而且这块内容比较容易被误解，增加了对内存泄漏发生情况的说明

如果 ThreadLocal 对象失去所有强引用（无论它定义在何处），并且线程持续存活，就可能导致内存泄漏。 虽然 ThreadLocalMap 自身有清理 key 为 null 的 entry 的机制，但这是一种被动清理，并不完全可靠。 为了避免内存泄漏，最佳实践是在使用完 ThreadLocal 后，主动调用 ThreadLocal.remove() 方法清除对应的 entry。

[1020325258]

并发相关内容： 1、关于 synchronized 相关内容较少，补充其中偏向锁被废弃原因 2、ThreadLocal 的内存泄漏解释的比较含糊，而且这块内容比较容易被误解，增加了对内存泄漏发生情况的说明

如果 ThreadLocal 对象失去所有强引用（无论它定义在何处），并且线程持续存活，就可能导致内存泄漏。 虽然 ThreadLocalMap 自身有清理 key 为 null 的 entry 的机制，但这是一种被动清理，并不完全可靠。 为了避免内存泄漏，最佳实践是在使用完 ThreadLocal 后，主动调用 ThreadLocal.remove() 方法清除对应的 entry。

奥奥对，我写的确实片面了，还是Guide哥写的清楚

[Snailclimb]

并发相关内容： 1、关于 synchronized 相关内容较少，补充其中偏向锁被废弃原因 2、ThreadLocal 的内存泄漏解释的比较含糊，而且这块内容比较容易被误解，增加了对内存泄漏发生情况的说明

如果 ThreadLocal 对象失去所有强引用（无论它定义在何处），并且线程持续存活，就可能导致内存泄漏。 虽然 ThreadLocalMap 自身有清理 key 为 null 的 entry 的机制，但这是一种被动清理，并不完全可靠。 为了避免内存泄漏，最佳实践是在使用完 ThreadLocal 后，主动调用 ThreadLocal.remove() 方法清除对应的 entry。

奥奥对，我写的确实片面了，还是Guide哥写的清楚

没关系的，这块案例我移除了哈，我不太想在面试题总结中加入太多比较复杂的案例，会影响整体阅读体验。

[1020325258]

并发相关内容： 1、关于 synchronized 相关内容较少，补充其中偏向锁被废弃原因 2、ThreadLocal 的内存泄漏解释的比较含糊，而且这块内容比较容易被误解，增加了对内存泄漏发生情况的说明

如果 ThreadLocal 对象失去所有强引用（无论它定义在何处），并且线程持续存活，就可能导致内存泄漏。 虽然 ThreadLocalMap 自身有清理 key 为 null 的 entry 的机制，但这是一种被动清理，并不完全可靠。 为了避免内存泄漏，最佳实践是在使用完 ThreadLocal 后，主动调用 ThreadLocal.remove() 方法清除对应的 entry。

奥奥对，我写的确实片面了，还是Guide哥写的清楚

没关系的，这块案例我移除了哈，我不太想在面试题总结中加入太多比较复杂的案例，会影响整体阅读体验。

好滴，明白