macOS: JDTLS java process shows “Not Responding” in Activity Monitor

[Shawyeok]

Environment

• macOS version: 26.1
• Extension: Language Support for Java(TM) by Red Hat version: 1.50.0
• JDK used by JDTLS (java -version and/or ps command line): 21.0.9-macosx-aarch64
• ps -ef output

  502 17937 17590   0  6:19PM ??         7:25.31 /Users/<user>/.cursor/extensions/redhat.java-1.50.0-darwin-arm64/jre/21.0.9-macosx-aarch64/bin/java --add-modules=ALL-SYSTEM --add-opens java.base/java.util=ALL-UNNAMED --add-opens java.base/java.lang=ALL-UNNAMED --add-opens java.base/sun.nio.fs=ALL-UNNAMED -Declipse.application=org.eclipse.jdt.ls.core.id1 -Dosgi.bundles.defaultStartLevel=4 -Declipse.product=org.eclipse.jdt.ls.core.product -Djava.import.generatesMetadataFilesAtProjectRoot=false -DDetectVMInstallationsJob.disabled=true -Dfile.encoding=utf8 -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx2G -Xms100m -Xlog:disable -javaagent:/Users/<user>/.cursor/extensions/redhat.java-1.50.0-darwin-arm64/lombok/lombok-1.18.39-4050.jar -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/<user>/Library/Application Support/Cursor/User/workspaceStorage/b073665c2bc84ec3e79c32587934d14c/redhat.java -Daether.dependencyCollector.impl=bf -jar /Users/<user>/.cursor/extensions/redhat.java-1.50.0-darwin-arm64/server/plugins/org.eclipse.equinox.launcher_1.7.100.v20251111-0406.jar -configuration /Users/<user>/Library/Application Support/Cursor/User/globalStorage/redhat.java/1.50.0/config_mac -data /Users/<user>/Library/Application Support/Cursor/User/workspaceStorage/b073665c2bc84ec3e79c32587934d14c/redhat.java/jdt_ws --pipe=/private/var/folders/cp/bcjqx5q56h7gp_3kts42xglm0000gp/T/lsp-aa7656daf3ce78c3a57214fd2e50ecf6.sock

Repro / When it happens

• Project type: Maven/Gradle
• Steps leading to hang:
• Does it recover on its own? No

Observed

• Activity Monitor shows java (Not Responding) PID 17937 with low CPU

Attachments

• threadump of java process 17937.vscode-java-plugin.txt
• Cursor Output (Java) logs + Extension Host logs

Dec 24, 2025 6:19:17 PM org.apache.aries.spifly.BaseActivator log
INFO: Registered provider ch.qos.logback.classic.spi.LogbackServiceProvider of service org.slf4j.spi.SLF4JServiceProvider in bundle ch.qos.logback.classic
Dec 24, 2025 6:28:44 PM com.microsoft.java.debug.plugin.internal.JavaDebuggerServerPlugin start
INFO: Starting com.microsoft.java.debug.plugin
Dec 24, 2025 6:31:26 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 214
Dec 24, 2025 6:36:01 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 977
Dec 24, 2025 6:46:24 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 2084
Dec 24, 2025 6:47:47 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 2432
Dec 24, 2025 6:52:33 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 2883
Dec 24, 2025 8:28:39 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 4289
Dec 24, 2025 8:28:39 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 4286
Dec 24, 2025 8:28:39 PM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 4293
Dec 25, 2025 10:32:20 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 5863
Dec 25, 2025 10:42:54 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 6305
Dec 25, 2025 10:42:54 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 6307
Dec 25, 2025 10:42:54 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 6308
Dec 25, 2025 10:42:54 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 6309
Dec 25, 2025 10:42:54 AM org.eclipse.lsp4j.jsonrpc.RemoteEndpoint handleCancellation
WARNING: Unmatched cancel notification for request id 6310

[Marsmhl]

Mark

[snjeza]

This is an upstream buildship issue. See eclipse-buildship/buildship#1358

[tienduochds]

Any workaround for it?

[amimobenja]

Root Cause Analysis

I've investigated this issue in detail and identified the exact cause:

The Problem

The JDT LS process becomes orphaned when the LSP named pipe socket file is deleted while the Java process is blocked in a native socket read. The process is stuck indefinitely at:

sun.nio.ch.SocketDispatcher.read0(Native Method)
↳ ConnectionStreamFactory$NamedPipeInputStream.read()
↳ StreamMessageProducer.listen()

Key finding: The socket file (e.g., /private/var/folders/.../lsp-*.sock) no longer exists, but the Java process doesn't detect this and remains blocked forever.

How it happens

1. VS Code/Cursor extension host crashes, reloads, or the workspace is closed unexpectedly
2. The socket file is cleaned up by the system or VS Code
3. The Java process never receives notification that the socket is gone
4. It remains stuck in read0() - a blocking native call that doesn't check for socket validity
5. macOS marks it "Not Responding" because it can't respond to system signals while blocked

Environment (my case)

• macOS 26.1 (Darwin 25.3.0)
• Extension: Language Support for Java v1.52.0
• JDK: 21.0.9-macosx-aarch64 (bundled)
• Process had been running for ~2.2 hours with deleted socket

Suggested Fix

The extension should either:

1. Use non-blocking I/O with select/poll - Check socket validity periodically
2. Implement a heartbeat mechanism - Detect when the parent connection is dead
3. Register for SIGPIPE - Get notified when the pipe breaks
4. Check socket file existence - Periodic check if the socket file still exists
5. Clean up child processes on extension deactivation - Ensure the Java process is terminated when the extension host dies

Workaround

For affected users on macOS, here's a launchd agent that automatically cleans up orphaned JDT LS processes every 30 minutes:

Create ~/Library/LaunchAgents/com.user.cleanup-jdtls.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.cleanup-jdtls</string>
    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>-c</string>
        <string>for pid in $(pgrep -f jdt.ls.core 2>/dev/null); do sock=$(ps -p $pid -o args= 2>/dev/null | grep -oE "/private/var/folders[^ ]*\.sock"); [ -n "$sock" ] &amp;&amp; [ ! -e "$sock" ] &amp;&amp; kill $pid 2>/dev/null &amp;&amp; logger "Killed orphaned JDT LS process: $pid"; done</string>
    </array>
    <key>StartInterval</key>
    <integer>1800</integer>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Then load it:

launchctl load ~/Library/LaunchAgents/com.user.cleanup-jdtls.plist

This checks every 30 minutes for JDT LS processes whose socket files no longer exist and terminates them.