*bug report* ProcessorSlot的Spi中的isSingleton = false设置不生效

[hulalaga]

Issue Description

Type: bug report

Describe what happened (or what feature you want)

当在非单例模式的ProcessorSlot（A）前加一个单例模式的ProcessorSlot（B）后，所有ProcessorSlotChain中B的next都会同步修改为最新创建的A

Describe what you expected to happen

在上述行为后，不同的ProcessorSlotChain中B的next应该为各自新创建的A，而非共同的A

How to reproduce it (as minimally and precisely as possible)

1. 添加一个ProcessSlot实现类，添加注解@SPI(order = Spi.ORDER_HIGHEST)

Tell us your environment

sentinel 1.8.3

Anything else we need to know?

DefaultProcessorSlotChain中添加next的方式是直接修改传入的AbstractLinkedProcessorSlot，但是传入的ProcessorSlot有可能是单例或非单例，倘若是单例，则在其后添加next会影响所有的ProcessorSlotChain

[sczyh30]

cc @cdfive

[githubcheng2978]

能否使用两个ProcessorSlot没有直接联系的方式，但只有顺序的方式实现。例如数组

[quguai]

如果要实现的话,感觉必须抛弃传统的链式调用, 单例对象持有的next对象一定也是唯一的.
数组是一个不错的实现方式,上下节点之间不存在明显的引用关系

[weixq709]

是否可以使用Wrapper包装Slot节点，使其每个节点为原型对象，然后将所有方法委托给目标对象来解决这个问题。并且只需要修改少量代码

public void addLast(AbstractLinkedProcessorSlot<?> protocolProcessor) {
        PrototypeDelegateSlot processor = new PrototypeDelegateSlot(protocolProcessor);
        end.setNext(processor);
        end = processor;
}```

@sczyh30 

[TwistedRiCen]

I reviewed the current 1.8 (repository default) and master implementations. The issue is still reproducible by code inspection:

1. SpiLoader reuses a singleton slot B but creates a new prototype slot A for each build().
2. DefaultProcessorSlotChain.addLast stores linkage directly in the slot instance via end.setNext(...).
3. After building chain1: B -> A1 and then chain2: B -> A2, both chains reference the same B, so the second build overwrites B.next with A2. Invoking chain1 then reaches A2.

The built-in ordering currently puts the two prototype slots first, so the stock chain normally avoids the unsafe singleton-to-prototype edge. A custom SPI slot can still create it.

There are already two overlapping open PRs, but both need design work before merge:

• Fix invalid prototype slot node issue #3616: a plain delegate wrapper owns the chain-local next, but existing slots call fireEntry/fireExit on the delegate itself. Those methods read the delegate's own next, not the wrapper's, so downstream propagation can stop after the first wrapped slot. The added test checks topology but does not execute the full entry/exit chain.
• fix: ensure each ProcessorSlotChain gets independent slot instances #3620: the current patch reflectively creates fresh instances. This bypasses @Spi(isSingleton = true) semantics and can break stateful custom singleton slots. Its fallback to the original instance also reintroduces the bug when reflective construction fails.

The smallest semantically correct direction appears to be separating chain-local linkage from the SPI handler lifecycle: a per-chain context/node owns next, while the delegate remains singleton or prototype according to @Spi. To remain compatible with existing AbstractLinkedProcessorSlot implementations, the design also needs a scoped continuation bridge for fireEntry/fireExit (including nested calls, exceptions, exit, and cleanup); a simple wrapper alone is insufficient.

A minimal regression test should build two chains with the same recording B and distinct A1/A2, build chain2 after chain1, invoke chain1, and assert only A1 is reached. This fails before the fix and tests behavior rather than wrapper identity.

Could a maintainer confirm whether this chain-context direction is acceptable and whether #3616/#3620 should be consolidated? To avoid a third duplicate PR, I would not start another implementation until that direction is confirmed.