从现有资料里，能确认的点主要有这些：

1. 在 Java 里调用存储过程，推荐使用 CallableStatement，并按 call 包名.存储过程名(?) 这种形式准备语句，再逐个设置参数后执行；文档示例也是这样做的，而不是直接把参数值硬编码进 SQL 字符串里执行。[1]

2. InterSystems 文档明确提到，调用存储过程时，语句必须为 SQL 所要求的每一个 input 或 input/output 参数都提供参数。如果参数个数或类型理解不一致，就可能出现你描述的这类 “Parameter list mismatch” 问题。[2]

3. 另外，InterSystems 也明确提到，JDBC 相关问题里有一类就是：“Caché 对 JDBC 的理解”和“远端数据库/驱动对 JDBC 的理解”之间存在不匹配，其中就包括 stored procedure with output parameters。这种场景官方建议通过日志分析实际发送内容，并用独立 Java 程序复现来定位。[3]

基于这些资料，你现在可以这样检查：

• 不要只在 Java 中直接执行
  
  CALL DHCXXXXice.MKPIQuery_QueryXXXX('K007XXXX.JJR','2024-08-01','2024-08-01')
  
  而应改成使用 CallableStatement，例如先准备类似
  
  call DHCXXXXice.MKPIQuery_QueryXXXX(?,?,?,?,?,?,?,?)
  
  这样的语句，再逐个绑定参数后执行。[1][2]

• 既然你查到该存储过程“可接收参数为 8 个”，那 Java 侧需要确认：这 8 个参数里哪些是 input，哪些是 output / input-output。因为文档特别指出，存储过程调用时需要为每个必需的 input 或 input/output 参数提供参数；而涉及 output 参数时，JDBC 与数据库之间更容易出现不匹配问题。[2][3]

• 如果连接工具能查出来、Java 代码不行，资料建议的定位方式是：

  1. 启用 JDBC 驱动日志，方法是在 JDBC 连接串末尾追加日志文件名，例如
     
     jdbc:Cache://127.0.0.1:1972/USER/jdbc.log，日志会写到 Java 应用工作目录。[3]
  2. 写一个最小化 Java 复现程序，只保留连接、prepareCall、参数绑定、执行这几个步骤，用来确认究竟是参数绑定方式、过程签名，还是驱动/数据库对过程参数的解释存在差异。[3]

3 中还有一句和你这个场景非常相关：

[!NOTE]

This reference lists only the extension methods and variants discussed elsewhere in this document. See "JDBC Driver Support" in the Implementation Reference for Java Third Party APIs for a complete description of all InterSystems JDBC driver features, including extensions, variants, and implementation of optional JDBC features. [4]

以及 11 中的关键限制：

[!IMPORTANT]

The name of the stored procedure is case-sensitive. Also, make sure that the pQueryStatement statement supplies an argument for every input or input/output parameter that the SQL query requires. [2]

所以，单从资料能得出的结论是：你的问题更像是 Java/JDBC 对该存储过程参数签名的调用方式不正确，或者该过程包含 output / input-output 参数，导致 JDBC 调用时参数列表解释与连接工具不同。[3][2]

如果你愿意，我可以下一步帮你把这个调用改写成一个标准的 Java CallableStatement 示例模板，方便你直接对照代码排查。[1]

Sources:

你这个现象更像是 Studio 里的 project 没有自动重新打开，而不是项目本身丢了。

文档里说明，project 是一组类定义和例程的集合，作用之一就是让你下次启动 Studio 时更容易回到之前的工作；启动后，打开该 project，Workspace 窗口里的 Project 标签页才会显示这些内容。[1]

如果你关闭了 workspace / project 之后，再打开看不到 project，文档给出的相关操作是：

• 用 File > Open Project... 打开当前 IRIS 服务器和命名空间中的已有 project。[2]
• 或者用 File > Recent Projects... 打开最近使用过的 project。[2]
• 如果只是把当前 project 关掉了，可以用 File > Close Project / Open Project... 重新打开。[2]

还有一个容易混淆的点：project 只属于当前 server 和 namespace。文档明确说：

• project 只能包含当前 InterSystems IRIS namespace 中可见的内容。[1]
• Open Project... 也是打开“当前 InterSystems IRIS server 和 namespace”里的 project；如果是别的 namespace 或别的 server，需要先 File > Change Namespace 或 File > New Studio。[2]

所以你现在“只能从最近的 workspace/project 里找回来”，很可能是因为当前会话里 没有自动打开 project，或者你重新进入时 server / namespace 和之前不一样，于是当前 workspace 的 Project 标签页就空了，需要手动重新打开对应的 project。[1][2]

另外，文档还提到：

[!IMPORTANT]

InterSystems® Studio has been deprecated. Beginning with version 2024.2, it is no longer included with installations of InterSystems IRIS®, and it is no longer receiving maintenance updates. An upgrade to InterSystems IRIS 2024.2 or later will remove any Studio installation which is associated with the instance. [1]

如果你愿意，我可以继续帮你把这个情况拆成“到底是 Close Workspace/Close Project 导致的”，还是“切换了 namespace 导致 project 看不到”的排查步骤。[1][2]

Sources:

不需要、也不建议在 WaitForComplete()（或 Sync()）之后立刻手工去杀 %SYSTEM.WorkMgr 创建的子进程。EVTW 状态通常表示这些 worker 进程还在线，等待后续的 Work Queue 请求；这样做是为了避免下次再启动新进程的开销。它们应当会在一段时间后自动超时清理，因此一般可以直接放着不管。[1]

你看到“过一会儿它们会消失，留一个它不会消失”，从已有资料看，这与 Work Queue Manager 的设计一致：系统会保留 worker 进程以便复用，下次有新的工作项时可以直接接上，而不是每次重新创建进程。[1]

如果你用 $SYSTEM.Process.Terminate(pid) 去结束这些 worker，产生错误信息并不奇怪。文档说明这个方法对其他进程的效果等同于 ^RESJOB，也就是强制终止进程；这不是 %SYSTEM.WorkMgr 推荐的正常结束方式。[2]

关于“为什么会导致服务器出问题”，现有资料并没有支持“这些处于 EVTW 的空闲 worker 本身会消耗明显 CPU 或内存并直接导致服务器卡顿”的结论。相反，社区回复明确说这些 worker “不应消耗显著的内存或 CPU”，并且会自动超时，所以通常应当让它们自行清理。[1]

更正确的使用方式是：

1. 创建 work queue。
2. 用 Queue()/QueueCallback() 加入工作项。
3. 调用 Sync()（或你提到的 WaitForComplete()）等待完成。
   
   这是文档给出的标准流程。[3]

另外，要避免 WorkMgr 使用过程中出现异常或残留影响，关键不在于“快速杀掉子进程”，而在于保证你的工作单元代码满足 Work Queue 的要求，尤其是：

• 工作单元彼此独立；[3]
• 返回 %Status，让 Sync() 能汇总总体结果；[3]
• 如果多个工作单元会修改同一 global，需要自己设计锁策略；[3]
• 代码里不要使用 exclusive NEW、KILL 或 unLOCK，因为这会干扰框架；[3]
• 工作单元调用的任何逻辑都必须正确清理，不要留下变量、锁、进程私有全局或其他残留，因为同一个 worker 进程会被后续完全不同的工作项复用。[3]

如果你的实际问题是“多次调用后越来越多，想让每次都马上退出”，当前检索结果里没有提供 %SYSTEM.WorkMgr 的公开“立即销毁全部 worker”方法，因此不能据此给出这种做法。[1][3]

[!NOTE]

The %SYSTEM.WorkMgr class supports more complex workflows with the methods described in other topics. [3]

如果你怀疑服务器异常不是“空闲 EVTW 进程”本身造成的，更应优先检查你的工作单元是否留下了锁、变量或其他运行痕迹，因为同一进程会被后续工作项重复使用；这正是文档特别强调要清理干净的原因。[3]

补充一点：如果根本不调用 Sync() / WaitForComplete()，已有讨论指出，work queue 对象一旦离开作用域，可能导致该 work queue 组中的工作单元被终止，因此通常还是需要调用它们作为同步点，并接收错误报告。[4]

Sources: