Think of your Java application like a busy office. Data is the paperwork. It arrives in files, comes through the network, and needs to be sorted, read, and sent out. For a long time, this office used slow, cumbersome methods. A clerk (a thread) would start reading a file and just sit there, staring at the disk, doing nothing else until the entire file was in memory.

That doesn’t work in a modern, fast-paced world. We need our office to be efficient. One clerk should be able to manage multiple tasks, not get stuck waiting. Today, Java offers a much better toolbox for this. I want to share some of the most effective techniques I use to handle data movement and communication. These methods help build applications that are quick, responsive, and can handle a lot of work without breaking a sweat.

Let’s start with the basics: dealing with files on your computer. The old way used the File class. It worked, but it was a bit clunky. The modern approach uses java.nio.file, and the two main tools you need are Path and Files. A Path is just a reference to a location, like “C:\work\data.txt” or “/home/user/logs”. The Files class is where the real action happens.

Here’s a simple example. Imagine you need to back up a log file, appending a timestamp to its name.

Path source = Paths.get("logs/application.log");
Path target = Paths.get("archive/application_" + System.currentTimeMillis() + ".log");

// First, let's check if our source file is even there.
if (Files.notExists(source)) {
    System.err.println("Cannot find the log file to back up.");
    return;
}

// We can get useful information easily.
System.out.println("Backing up file, size: " + Files.size(source) + " bytes");

// Now, copy it. We want to replace any file with the same name and keep its timestamps.
Files.copy(source, target, StandardCopyOption.REPLACE_EXISTING, StandardCopyOption.COPY_ATTRIBUTES);

// Maybe we want to quickly check for errors as we back up.
try (Stream<String> lines = Files.lines(source, StandardCharsets.UTF_8)) {
    long errorCount = lines.filter(line -> line.contains("ERROR")).count();
    System.out.println("Found " + errorCount + " error lines in the log.");
}

This feels cleaner and more powerful than the old FileInputStream and FileOutputStream dance. The Files class handles errors more clearly, works well with links, and provides methods for almost anything you want to do.

Now, what if you’re dealing with a truly massive file? You can’t just load it all into memory. You need to read it in pieces. This is where buffering comes in. Think of it like moving furniture through a narrow doorway. You don’t shove the whole couch through at once; you go piece by piece.

Path largeFile = Paths.get("huge_database_dump.sql");

// Using a buffered stream is a classic, reliable method.
try (InputStream is = Files.newInputStream(largeFile);
     BufferedInputStream bis = new BufferedInputStream(is, 16384)) { // Using a 16KB buffer
    byte[] chunk = new byte[4096];
    int bytesRead;
    while ((bytesRead = bis.read(chunk)) != -1) {
        // Process this 4KB chunk of data.
        processChunk(chunk, bytesRead);
    }
}

For some special cases, like a huge file where you need to jump to random spots, you can use a memory-mapped file. It lets the operating system treat part of the file as if it’s already in memory.

try (FileChannel channel = FileChannel.open(largeFile, StandardOpenOption.READ)) {
    MappedByteBuffer mappedBuffer = channel.map(FileChannel.MapMode.READ_ONLY, 0, channel.size());
    // Now 'mappedBuffer' acts like a large array in memory, but it's backed by the file.
    if (mappedBuffer.hasRemaining()) {
        int firstByte = mappedBuffer.get();
        // You can jump around using mappedBuffer.position(someIndex)
    }
}

This is very fast for random access but remember, it asks the OS for a large block of address space. Use it wisely.

Files are one thing, but modern applications live on the network. They talk to APIs, fetch data, and send messages. For years, Java’s built-in tool for this, HttpURLConnection, was difficult to use. It felt outdated. Since Java 11, we have a new, proper HTTP client in java.net.http. It’s like getting a modern smartphone after using a old flip phone.

It supports the newer HTTP/2 protocol, which can make things faster, and it does both synchronous and asynchronous calls easily. Let me show you.

// First, we build our HTTP client. We can set timeouts and other policies here.
HttpClient client = HttpClient.newBuilder()
    .version(HttpClient.Version.HTTP_2) // Prefer HTTP/2
    .connectTimeout(Duration.ofSeconds(5))
    .build();

// Next, we build our request.
HttpRequest request = HttpRequest.newBuilder()
    .uri(URI.create("https://jsonplaceholder.typicode.com/posts/1"))
    .header("Accept", "application/json")
    .GET() // This is a GET request. We could do .POST() and add a body.
    .build();

// Simple synchronous call. The thread waits for the response.
try {
    HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
    System.out.println("Status Code: " + response.statusCode());
    System.out.println("Response Body:\n" + response.body());
} catch (IOException | InterruptedException e) {
    e.printStackTrace();
}

The synchronous call is straightforward. But the real power is in not waiting. Your application can fire off a request and move on to other work, getting notified when the response arrives.

// Asynchronous call - doesn't block the current thread.
client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
    .thenApply(HttpResponse::body) // When done, get the body.
    .thenAccept(body -> System.out.println("Async response: " + body)) // Then print it.
    .exceptionally(e -> { // Handle any errors.
        System.err.println("Request failed: " + e.getMessage());
        return null;
    });

// Code here runs immediately, without waiting for the network call.
System.out.println("Request sent, moving on to other tasks...");

This model is perfect for building responsive user interfaces or services that call multiple external APIs. You don’t need a separate thread pool just for HTTP calls anymore; the client manages it.

Often, the data you get from the network is JSON. Libraries like Jackson are great for converting JSON into Java objects. But what if you get a gigantic JSON file, like a database export or a long stream of events? Creating objects for everything can fill up your memory.

For this, you can use a streaming approach. Instead of building the whole house (the object model) at once, you look at the bricks (the tokens) one by one.

JsonFactory factory = new JsonFactory();
try (JsonParser parser = factory.createParser(new File("massive_data.json"))) {
    // We walk through the JSON token by token.
    while (parser.nextToken() != null) {
        JsonToken currentToken = parser.currentToken();
        
        // If we find a field named "email", we process its value.
        if (currentToken == JsonToken.FIELD_NAME && "email".equals(parser.currentName())) {
            parser.nextToken(); // Move from the field name to its value.
            String emailAddress = parser.getText();
            System.out.println("Found email: " + emailAddress);
            // We could validate it or add it to a set without ever creating a full User object.
        }
    }
}

You can do the same for writing JSON. This is incredibly efficient for processing large datasets where you only need a few fields.

So far, a lot of our file work has been synchronous. Our code waits for the read or write to finish. Java also offers a way to do file I/O asynchronously, using callbacks. It’s like ordering food and leaving your phone number. You don’t stand at the counter; you go sit down, and they call you when it’s ready.

Path dataFile = Paths.get("bulk_data.dat");
AsynchronousFileChannel channel = AsynchronousFileChannel.open(dataFile, StandardOpenOption.READ);

ByteBuffer buffer = ByteBuffer.allocateDirect(4096); // Direct buffer can be faster for I/O.

// This starts the read operation and immediately returns control.
channel.read(buffer, 0, buffer, new CompletionHandler<Integer, ByteBuffer>() {
    
    @Override
    public void completed(Integer bytesRead, ByteBuffer attachment) {
        // This method is called later, when the OS has read the data.
        System.out.println("Successfully read " + bytesRead + " bytes.");
        attachment.flip(); // Prepare buffer to be read.
        // ... process the data in the buffer ...
        try { channel.close(); } catch (IOException e) { /* handle */ }
    }

    @Override
    public void failed(Throwable exc, ByteBuffer attachment) {
        // Called if something goes wrong.
        System.err.println("File read failed: " + exc);
    }
});

// This line runs right after starting the read, not after it finishes.
System.out.println("Read operation initiated, main thread is free.");

This model is powerful but requires you to manage buffers and lifecycle carefully. It’s great for applications that must stay perfectly responsive, like a GUI tool processing large files.

When we move to raw network programming, like building a custom server, we face the same blocking problem. The old socket API would make a thread wait for each client. For a server that needs to handle thousands of connections, that’s impossible. The solution is non-blocking channels and a Selector.

A Selector is a single thread that can watch hundreds of network sockets. It shouts “Hey, this socket is ready for reading!” or “This new client is trying to connect!” Your code then handles just that event.

// Create the main selector, the traffic controller.
Selector selector = Selector.open();
ServerSocketChannel serverSocket = ServerSocketChannel.open();
serverSocket.bind(new InetSocketAddress(7070));
serverSocket.configureBlocking(false); // This is the key: make it non-blocking.

// Register the server socket with the selector. We're interested in 'accept' events.
serverSocket.register(selector, SelectionKey.OP_ACCEPT);

System.out.println("Server started on port 7070");

while (true) {
    // This waits until at least one registered channel has an event.
    selector.select();
    
    // Get the keys for the channels that have events.
    Set<SelectionKey> selectedKeys = selector.selectedKeys();
    Iterator<SelectionKey> keyIterator = selectedKeys.iterator();
    
    while (keyIterator.hasNext()) {
        SelectionKey key = keyIterator.next();
        
        if (key.isAcceptable()) {
            // A new client is knocking. Accept the connection.
            ServerSocketChannel server = (ServerSocketChannel) key.channel();
            SocketChannel client = server.accept();
            client.configureBlocking(false);
            // Register this new client channel for read operations.
            client.register(selector, SelectionKey.OP_READ);
            System.out.println("New client connected: " + client.getRemoteAddress());
            
        } else if (key.isReadable()) {
            // A client has sent us data.
            SocketChannel client = (SocketChannel) key.channel();
            ByteBuffer readBuffer = ByteBuffer.allocate(128);
            int bytesRead = client.read(readBuffer);
            
            if (bytesRead == -1) {
                // Client disconnected.
                client.close();
                System.out.println("Client disconnected.");
            } else {
                // Process the data we just read.
                readBuffer.flip();
                byte[] data = new byte[readBuffer.remaining()];
                readBuffer.get(data);
                String message = new String(data);
                System.out.println("Received: " + message);
                // You could write a response back here.
            }
        }
        keyIterator.remove(); // Remove the key so we don't process it again.
    }
}

This pattern is the foundation of high-performance servers. It looks more complex, but it allows one thread to manage an enormous number of connections. Libraries like Netty build beautiful abstractions on top of this model.

One of my favorite ways to write clean, expressive code is by using the Streams API. It pairs wonderfully with I/O. Need to find the largest files in a directory? Parse a CSV? Streams make it a declarative process.

// Find all Java files modified in the last 24 hours.
Instant yesterday = Instant.now().minus(Duration.ofDays(1));

List<Path> recentJavaFiles = Files.walk(Paths.get("src/main/java"))
    .filter(Files::isRegularFile)
    .filter(p -> p.toString().endsWith(".java"))
    .filter(p -> {
        try {
            return Files.getLastModifiedTime(p).toInstant().isAfter(yesterday);
        } catch (IOException e) { return false; }
    })
    .collect(Collectors.toList());

System.out.println("Recently modified Java files: " + recentJavaFiles.size());

For processing text files line by line, Files.lines() is a gift.

// Calculate average line length in a file.
Path textFile = Paths.get("war_and_peace.txt");
try (Stream<String> lines = Files.lines(textFile)) {
    OptionalDouble average = lines
        .mapToInt(String::length)
        .average();
        
    if (average.isPresent()) {
        System.out.printf("Average line length: %.2f characters%n", average.getAsDouble());
    }
}
// The try-with-resources ensures the file is closed, which is crucial for streams from I/O sources.

Sometimes, you need to save space or bandwidth. Compressing data on the fly is simple. Let’s say you’re writing a lot of JSON logs.

String logEntry = "{\"time\": \"2023-10-27\", \"event\": \"user_login\", \"user\": \"alice\"}\n";

// Writing compressed data directly.
try (FileOutputStream fos = new FileOutputStream("app.log.gz");
     GZIPOutputStream gzipOS = new GZIPOutputStream(fos);
     OutputStreamWriter writer = new OutputStreamWriter(gzipOS, StandardCharsets.UTF_8)) {
    writer.write(logEntry);
    // Write more entries...
}
// The file 'app.log.gz' is created, already compressed.

Reading it back is just as easy.

try (GZIPInputStream gzipIS = new GZIPInputStream(new FileInputStream("app.log.gz"));
     BufferedReader reader = new BufferedReader(new InputStreamReader(gzipIS))) {
    reader.lines().forEach(System.out::println);
}

This is a huge win for network transmission or storing large amounts of textual data. The CPU does a little extra work, but you save a lot of I/O time.

In many applications, you need a place to scribble down temporary data. Maybe you’re downloading an image to process, or creating an intermediate file for a sort operation. Java helps you create temporary files safely.

The key is to not guess a filename. Let the system give you a unique one, and always clean up.

// Create a temporary file with a prefix and suffix.
Path tempFile = Files.createTempFile("myapp_cache_", ".tmp");
System.out.println("Using temp file: " + tempFile);

try {
    // Write some data to it.
    Files.write(tempFile, someImportantData);
    
    // ... do your work with the file ...
    
} finally {
    // Delete it when we're done. This is manual cleanup.
    Files.deleteIfExists(tempFile);
}

For even better safety, you can ask for the file to be deleted automatically when your program ends, or even when you close the handle to it.

// This option deletes the file as soon as the channel is closed.
try (SeekableByteChannel channel = Files.newByteChannel(
        Files.createTempFile("scratch_", ".dat"),
        StandardOpenOption.READ,
        StandardOpenOption.WRITE,
        StandardOpenOption.DELETE_ON_CLOSE)) {
    // Work with the channel...
} // File is gone now, automatically.

This prevents temp files from littering the disk if your application crashes.

Finally, how do you know if your I/O is efficient? You can guess, or you can use data. The JDK includes a powerful profiling tool called Flight Recorder. It’s like having a dashboard that shows you exactly where your application spends its time, especially on disk and network calls.

You can start it from the command line when you launch your app.

java -XX:StartFlightRecording=filename=myrecording.jfr,duration=60s -jar MyApplication.jar

This records 60 seconds of runtime data into a file. You then open this file in another tool called JDK Mission Control (it’s in your JDK’s bin folder). Inside, you can look for specific events. Look for File Read, File Write, Socket Read, and Socket Write events.

These events tell you how long each operation took and how many bytes were involved. If you see thousands of tiny file reads, you might need better buffering. If you see socket reads taking several seconds, your network connection or the remote service might be slow. This evidence is invaluable for fixing performance problems. You move from “I think it’s slow” to “I can see the 200-millisecond disk reads are the bottleneck.”

These techniques have changed how I write Java applications. Moving from old, blocking code to models that work with the system, not against it, makes a dramatic difference. It’s about making your data office efficient. The clerk shouldn’t stand idle waiting for the mail. They should process one letter, file it, and immediately move to the next task, or better yet, get notified when the next batch arrives. By using modern paths, non-blocking network calls, asynchronous patterns, and streaming data, you build applications that are ready for the scale and speed users expect today. Start with one technique, like replacing your old HTTP calls with the new client, and you’ll feel the improvement immediately.