review时的一些疑惑

[1229256875]

• Syp的入口处调用了函数 java.com.alibaba.jvm.sandbox.spy.Spy$SelfCallBarrier.isEnter(Thread)， 采用分段锁的形式来拦截一个线程多次进入，也就是拦截可能出现的循环调用
• Sandbox守护者 com.alibaba.jvm.sandbox.core.util.SandboxProtector 是通过ThreadLocal计数器的方式来拦截同一个线程在sandbox中的多次进入
• 那么我的疑惑是，ThreadLocal的方式进行拦截，不管是计数器或者布尔值模式，在理论上讲，都比分段锁的方式性能消耗更少，那为什么在Spy的入口处还是采用了分段锁的方式进行拦截
• 初次提issue， 如果有什么说的不对的地方，请谅解

[oldmanpushcart]

要了解这个，逻辑会有点深：jvm-sandbox是怎么做到自己不观察到自己的？

这里核心的魔法使Spy.SelfCallBarrier，在Barrier保护区域之内的类都是可以被jvm-sandbox进行字节码增强观察的，但Barrier之外的类，则会引起递归死循环。所以整个Spy都在尽力自己实现所有使用到的Java类，尽量减少对其他类的使用。当前还有ReentrantLock还没有实现完全"国产化"

SandboxProtector的确是很高效的一个重入守护设计，但他是通过ThreadLocal来实现的。在jvm-sandbox的淘宝应用场景中有直接对ThreadLocal进行增强观测的需求，但SandboxProtector由ThreadLocal实现的特性导致了自己将会观察到自己。

[1229256875]

如果只是因为需要观测ThreadLocal所导致的循环的话， 那么是否可以对 SandboxProtector中的ThreadLocal进行继承，进行国产化，然后再spy入口排除掉SandboxProtector中的ThreadLocal这个对象所进行的操作呢，我可以这样理解吗

[oldmanpushcart]

不可以，继承ThreadLocal不能叫国产化，这个和“汉芯”磨皮有得一拼。
"国产化"是实打实的，全部自己重写，尽量减少使用JDK封装的对象，越少越好

[1229256875]

不哈意思，我对所谓"国产化"理解存在误区。
就这个问题而言，我讨论的重点在于，SandboxProtector中的对象继承ThreadLocal类， 变成一个sandbox包名的类，从而用来处理ThreadLocal.get() 或者ThreadLocal.set()被观测的情况，然后进行过滤。我后面做一个demo来验证这个情况。

[oldmanpushcart]

继承来的类，你底层还是得通过super.get()调用到ThreadLocal.get()

[Aresxue]

是否可以定制一个Thread实现类似ThreadLocal的功能，比如定义一个context，现有的ThreadLocal感觉并不是太好用，需要显式定义还需要手动清理。

[xl1605368195]

SelfCallBarrier.isEnter这个在系统cpu较高时（cpu>50%），性能急剧下降。如果不需要观察 threadlocal， 感觉可以去掉。

[oldmanpushcart]

是否可以定制一个Thread实现类似ThreadLocal的功能，比如定义一个context，现有的ThreadLocal感觉并不是太好用，需要显式定义还需要手动清理。

@Aresxue 有么？有实现了的么，借我“磨皮”下

[oldmanpushcart]

@xl1605368195 就算不观察ThreadLocal也去不掉呀