根据文档，
全局：组件在所有用户之间共享。会话：为每个用户提供组件的独立实例。
这意味着，对于全局组件，整个核心系统只有一个实例。。如果这是真的，那么它如何对"/atg/denamo/transaction/TransactionManager"等组件和大多数液滴有效。。？因为这些组件在同一时刻被几个用户使用
编辑：
我理解"TransactionManager"的行为。根据定义，应该有一个事务管理器，他应该为每个事务保留事务对象。但我的问题仍然适用于foreach、switch等飞沫（其中大多数都是全局范围的）如果整个核心系统只有一个对应类的实例，这不是对性能有不良影响吗？
从历史上看，ATG中有三种不同类型的作用域。随着Window（通常只在CSC应用程序中使用，所以尽量不要使用它）和Prototype（添加以支持Endeca墨盒处理程序的使用）的添加，这一数字现在已增加到5。
正如您在文档中强调的那样，全局组件实例化一次，由所有用户共享，而会话组件为给定会话创建一次，并由该会话的所有请求共享。类似地，每个使用请求的请求都会新实例化一个请求范围的组件
从性能的角度来看，解析到现有组件（例如ForEach等全局范围的组件）的路径需要一点时间，但实例化一个新对象（换句话说，请求范围内的组件）相对来说更昂贵
因此，在ForEach液滴的情况下，它被实例化一次，但在service方法中，它实际上从请求中提取参数：
String elementName = pRequest.getParameter(ELEMENT_NAME);
这意味着全局范围的组件是线程安全的，因为它只接受当前请求中的参数。因此，一般来说，如果一个组件可以由多个用户共享，而不必担心同步，那么它应该是全局范围的，而不是会话或请求范围的。（经验法则应该是，如果你的液滴是请求范围内的，那么你很可能做错了）。
如果您了解设计模式，$scope=global相当于使ATG组件成为单例。
ATG Commerce有4个不同范围的组件
- 全局：如果没有定义作用域，这是组件的默认作用域。这些组件将被初始化一次，并将作为全局对象。最好的做法是拥有所有的Droplets、Tools，Manager和其他全局配置组件
- 会话：所维护的范围和值对于每个一场通常使用的会话范围组件是ShoppingCart（订单）、配置文件、SearchFormHandler等
- 请求：对于每个请求，所维护的范围和值都是唯一的。通常使用的请求范围组件是FormHandlers，用于处理单个请求
- 窗口：范围和维护的值将是唯一的，直到浏览器窗口关闭。窗口范围组件
通常用于CSC应用程序中的ShoppingCart组件等。。使用基于业务的任何范围的组件都很好
要求，但将其声明为Global并使用它将是有利于提高应用程序的性能。这是一条经验法则，将业务逻辑放在全局范围的组件中，并在需要时从较低范围的组件引用它。这将减少等待垃圾回收的线程