检测编程语言中的尾递归

Question

这个问题有部分答案 here 和 here 这似乎暗示 javascript 和 python 会导致“无限递归”。

背景

最近我一直在涉足尾递归，据我目前的理解是，编程风格（*通常）具有等效迭代解决方案的性能优势和可读性优势 - 基本上使其成为两全其美.

示例

我注意到如果要在 .NET 或 Java 中执行此操作：

while(true) {...}

最终，Windows 会弹出一个对话框，允许机器用户更改此类可执行文件的状态：

问题

由于尾​​递归（*实际上）在这里不必处理 stackoverflow 异常，我是否错误地假设 Java 或 C# 会：

1. 触发“Foo.exe 无响应”对话框
2. 导致无限递归

此外，我假设此运行时“异常”将由语言的解释器处理是正确的？

Answer 1

由于尾​​递归（*实际上）在这里不必处理 stackoverflow 异常，我是否错误地认为 Java 或 C# 会...

这包含一个不正确的假设。

尾递归只是源代码中的一种模式。

尾递归优化将递归代码转换为可迭代的代码......在幕后。优化需要由编译器执行¹.

当前 Hotspot 实现中的 Java 编译器（字节码和 JIT）不进行尾递归优化。这有与安全相关的原因。

---

但忽略这一点：

我是否认为 Java 或 C# 会：

1. 触发“Foo.exe 无响应”对话框
2. 导致无限递归

还有第三种情况。它可能会进入无限循环而不会触发“未响应”警报。我的理解是，只有当操作系统检测到应用程序在一定秒数内没有“消耗”或“响应”待处理的 GUI 事件时，才会显示该警报。

我希望在以下情况下出现第三种情况：

• 测试应用程序没有 GUI
• 测试应用程序不在事件线程上运行递归测试
• 用户不会尝试以任何方式与测试应用程序 GUI 交互

此外，我假设此运行时“异常”将由语言的解释器处理是正确的？

如果 Java 中存在“堆栈溢出”事件，那么 JVM 运行时会将其转变为 StackOverflowError 异常。执行此操作的是解释器还是“其他东西”取决于...当时是否正在解释代码。

引发的异常被应用程序本身“处理”...或忽略。

---

^{1 - 为了迂腐，您可以在源代码级别手动执行优化，但是您的源代码不是递归的...}