arangodb的foxx什么时候收垃圾？
When does arangodb's foxx collects garbage?
我的理解是；
- Foxx 基于 V8 引擎。
- Foxx 是多线程的，它不与其他线程共享状态
- Foxx 的线程将在向客户端发送响应后立即退出（这是正确的术语吗？）。
除了 V8 Engine 的垃圾回收之外，是否意味着 foxx 使用的任何内存在做出响应后都会立即被垃圾回收？
如果以上问题的答案是肯定的，有没有办法禁用 V8 Engine 的垃圾收集器，如果我禁用 V8 Engine 的 GC，我可以期待更好的延迟吗？
如果我理解有误，请告诉我。
与许多其他口译员相比，javascript 口译员有一个特殊的功能。对于多个浏览器 windows，它们需要 运行，并且一个 Window 不应该知道另一个。
因此解释器操作集与其通用逻辑严格分离。在
V8 这个概念是在名称 Isolate 下实现的。
ArangoDB 产生了几个 Isolate，Foxx 可以 运行 进入每个 Isolate 的上下文。ArangoDB 的基础设施有连接到 Isolates 的钩子，可以发出信号，即新集合可用。但是，没有可以在 Foxx 中使用的此类挂钩。
ArangoDB 是多线程的。请求代理将读取请求，如果发现它应该执行 Foxx-Request（而不是直接 AQL 调用），它将从池中选择一个 Isolate，并在该 V8 上下文中继续执行。因此，既不能保证您到达同一个工作线程，也不能保证它会在后续请求中选择相同的 Isolate。
这些 Isolate 中的每一个都可以单独进行垃圾回收，而不会阻止其他 Isolate 中的执行。 ArangoDB Exposes statistics about these contexts , so you can see there that Isolates can be tagged dirty which means they should be garbage collected. You can use require("internal").wait(<seconds>, true) to manually invoke the garbage collection. The number of contexts spawned depends on the numbers of CPUs your system has. However, these settings can be configured. 所以你看到策略与调整 Java GC 完全不同。
Foxx 本身会在请求后丢弃由服务分配的结构。然后它们将在后续请求中不可用，一旦垃圾收集 运行s 它们的内存将返回给系统。
通常您应该努力使您的 Foxx 服务成为围绕您执行的 AQL 的薄层。
虽然性能应被视为一项功能，但您通常会在代码达到一定的成熟度后开始关注它。我们解释了howto create usage scenarios and measure and optimize possible throughputs in our blog post series；虽然那里没有直接提到 Foxx 服务，但那里使用的策略也可以应用于 Foxx。
我的理解是；
- Foxx 基于 V8 引擎。
- Foxx 是多线程的，它不与其他线程共享状态
- Foxx 的线程将在向客户端发送响应后立即退出（这是正确的术语吗？）。
除了 V8 Engine 的垃圾回收之外，是否意味着 foxx 使用的任何内存在做出响应后都会立即被垃圾回收？
如果以上问题的答案是肯定的，有没有办法禁用 V8 Engine 的垃圾收集器，如果我禁用 V8 Engine 的 GC，我可以期待更好的延迟吗？
如果我理解有误，请告诉我。
与许多其他口译员相比，javascript 口译员有一个特殊的功能。对于多个浏览器 windows，它们需要 运行，并且一个 Window 不应该知道另一个。
因此解释器操作集与其通用逻辑严格分离。在
V8 这个概念是在名称 Isolate 下实现的。
ArangoDB 产生了几个 Isolate，Foxx 可以 运行 进入每个 Isolate 的上下文。ArangoDB 的基础设施有连接到 Isolates 的钩子，可以发出信号，即新集合可用。但是，没有可以在 Foxx 中使用的此类挂钩。
ArangoDB 是多线程的。请求代理将读取请求，如果发现它应该执行 Foxx-Request（而不是直接 AQL 调用），它将从池中选择一个 Isolate，并在该 V8 上下文中继续执行。因此，既不能保证您到达同一个工作线程，也不能保证它会在后续请求中选择相同的 Isolate。
这些 Isolate 中的每一个都可以单独进行垃圾回收，而不会阻止其他 Isolate 中的执行。 ArangoDB Exposes statistics about these contexts , so you can see there that Isolates can be tagged dirty which means they should be garbage collected. You can use require("internal").wait(<seconds>, true) to manually invoke the garbage collection. The number of contexts spawned depends on the numbers of CPUs your system has. However, these settings can be configured. 所以你看到策略与调整 Java GC 完全不同。
Foxx 本身会在请求后丢弃由服务分配的结构。然后它们将在后续请求中不可用，一旦垃圾收集 运行s 它们的内存将返回给系统。
通常您应该努力使您的 Foxx 服务成为围绕您执行的 AQL 的薄层。 虽然性能应被视为一项功能，但您通常会在代码达到一定的成熟度后开始关注它。我们解释了howto create usage scenarios and measure and optimize possible throughputs in our blog post series；虽然那里没有直接提到 Foxx 服务，但那里使用的策略也可以应用于 Foxx。