[BUG] when submitting tasks in batches, em resources may exceed the threshold

[sjgllgh]

What is the purpose of the change

Fix bug: when submitting tasks in batches, em resources may exceed the threshold.

Related issues/PRs

Related issues: #4916

Brief change log

• Modify the DefaultResourceManager.java to fix the bug.

Checklist

• [x] I have read the Contributing Guidelines on pull requests.
• [x] I have explained the need for this PR and the problem it solves
• [x] I have explained the changes or the new features added to this PR
• [x] I have added tests corresponding to this change
• [x] I have updated the documentation to reflect this change
• [x] I have verified that this change is backward compatible (If not, please discuss on the Linkis mailing list first)
• [x] If this is a code change: I have written unit tests to fully verify the new behavior.

[peacewong]

The logical judgment here is considered as follows:

1. The ECM tag is not locked first for resource judgment. If the resource is judged, it will continue. Therefore, there is a certain probability of negative resources, but there will not be too many situations.
2. The reason for this consideration is to reduce lock waiting, because here is a concurrent lock grab, so the lock granularity should be as small as possible to reduce concurrency pressure.
3. If the usercreator lock is placed at a higher level, it will cause more lock waits.

这里的逻辑判断是这样考虑的：

1. ECM标签先不锁进行资源判断如果资源判断过就继续，所以存在一定概率出现负资源，但是不会出现太多情况
2. 之所以这样考虑是为了减少锁的等待，因为这里是并发抢锁的，所以锁的粒度尽量小减少并发压力
3. 如果把usercreator的锁放到更上一层，会导致更多的锁等待

[sjgllgh]

Thank you for your answer. Different scenarios may have different considerations.

The logical judgment here is considered as follows:

1. The ECM tag is not locked first for resource judgment. If the resource is judged, it will continue. Therefore, there is a certain probability of negative resources, but there will not be too many situations.
2. The reason for this consideration is to reduce lock waiting, because here is a concurrent lock grab, so the lock granularity should be as small as possible to reduce concurrency pressure.
3. If the usercreator lock is placed at a higher level, it will cause more lock waits.

这里的逻辑判断是这样考虑的：

1. ECM标签先不锁进行资源判断如果资源判断过就继续，所以存在一定概率出现负资源，但是不会出现太多情况
2. 之所以这样考虑是为了减少锁的等待，因为这里是并发抢锁的，所以锁的粒度尽量小减少并发压力
3. 如果把usercreator的锁放到更上一层，会导致更多的锁等待