How to Fix the Java.Net.BindException: Address Already in Use: Bind

To resolve java.net.BindException: Address already in use: Bind, identify which process (if any) owns the requested local address and port. Then either configure the server to use a free port or stop the confirmed process.

What the exception means

java.net.BindException: Address already in use: Bind means Java could not bind a socket to the requested local address and port. A listener may already own that port, but the message does not prove that another application is the cause. The requested address may also be unavailable, or the operating system may prevent the bind. Check the exact address and port in the startup configuration before changing anything.

For a server configured to listen on port 8080, first identify whether a process is listening there. Then choose whether to configure the server to use another port or to stop the identified process. Keep the existing port if clients, a proxy, or other services depend on it.

Find the process listening on the port

Replace 8080 below with the port from the error or server configuration. On Windows, run netstat -ano | findstr :8080 in Command Prompt or PowerShell. Find the row whose state is LISTENING; its final column is the process ID (PID). A matching connection in another state does not by itself show that a process is listening for new connections.

On macOS, run lsof -nP -iTCP:8080 -sTCP:LISTEN. On Linux, sudo ss -ltnp 'sport = :8080' shows listening TCP sockets and, with sufficient permissions, the owning process. If ss is unavailable, use sudo lsof -nP -iTCP:8080 -sTCP:LISTEN when lsof is installed. Older systems may provide netstat, but options and PID visibility vary; do not assume the same output format across Unix-like systems.

Record the PID and inspect its process name and command line before acting. The lookup may show no owner when permissions are limited, the service has exited, or the conflict involves a different local address or protocol. Repeat the check while the server is stopped if the listener appears only during startup.

Choose a fix

Changing the server port is usually appropriate when the existing listener is needed or when you control the server configuration. Stopping a process is appropriate only when you have confirmed what it does, who owns it, and that it is safe to stop. On shared or production machines, ask the service owner instead of terminating an unfamiliar process. A PID can be reused after a process exits, so verify the identity immediately before sending a stop command.

Change the server port

For Tomcat, edit the HTTP connector in server.xml and choose a free port that matches your deployment configuration. For example, change the connector’s port value from 8080 to 8880; keep the other connector attributes unchanged. In configuration terms, the relevant change is port="8080" to port="8880". Restart Tomcat after saving the file. Update clients, reverse proxies, firewall rules, and health checks that still target the old port.

Stop the process using the port

Use the PID found in the listener lookup, not a guessed number. On Windows, after confirming the process, run taskkill /PID 12345 in an appropriately authorized shell; add /F only if a normal termination fails and you have approval to force it. On macOS or Linux, send a normal termination with kill 12345. Avoid kill -9 unless the process will not stop cleanly and you understand the consequences. These commands require suitable permissions, and managed services are better stopped through their service manager so they can shut down cleanly.

Verify the fix

Run this example:

import java.io.IOException;
import java.net.ServerSocket;

public class BindCheck {
    public static void main(String[] args) throws IOException {
        try (ServerSocket server = new ServerSocket(0)) {
            System.out.println("Bound to an available port.");
        }
    }
}

This small Java example asks the operating system to assign an available port and closes the socket when the block ends. It is unexecuted in the supplied packet, so no observed output is claimed. After applying your server fix, start the actual service and check its startup log. Repeat the platform listener lookup using the selected port; confirm the expected service owns a listening socket, then connect through the same hostname and port that clients use. If startup still reports a bind failure, check the configured local address as well as the port and inspect the new error before changing another setting.