在过滤后的 HashMap 上运行 For-each 循环

Question

I am so new to java. and there is my problem.

I have a Map in Type of Map<Integer , List<MyObject>> that I call it myMap .

As myMap has a lot of members (About 100000) , I don't think the for loop to be such a good idea so I wanna filter my Map<Integer , List<MyObject>> Where the bellow condition happens:

myMap.get(i).get(every_one_of_them).a_special_attribute_of_my_MyObject == null ;

in which every_one_of_them means i wanna to delete members of myMap which the Whole list's members(All of its Objects) are null in that attribute(for more comfort , let's call it myAttribute ).

one of my uncompleted idea was such a thing:

Map<Integer, List<toHandle>> collect = myMap.entrySet().stream()
.filter(x -> x.getValue.HERE_IS_WHERE_I_DO_NOT_KNOW_HOW_TO)
.collect(Collectors.toMap(x -> x.getKey(), x -> x.getValue()));

Any Help Will Be Highly Appreciated. Thanks.

Answer 1

You can

• iterate over map values() and remove from it elements which you don't want. You can use for that removeIf(Predicate condition) .
• To check if all elements in list fulfill some condition you can use list.stream().allMatch(Predicate condition)

For instance lets we have Map<Integer, List<String>> and we want to remove lists which have all strings starting with b or B . You can do it via

myMap.values()
     .removeIf(list -> list.stream()
                           .allMatch(str -> str.toLowerCase().startsWith("b"))
// but in real application for better performance use 
//                         .allMatch(str -> str.regionMatches(true, 0, "b", 0, 1))

     );

DEMO:

Map<Integer , List<String>> myMap = new HashMap<>(Map.of(
        1, List.of("Abc", "Ab"),
        2, List.of("Bb", "Bc"),
        3, List.of("Cc")
));

myMap.values()
     .removeIf(list -> list.stream()
                           .allMatch(str -> str.toLowerCase().startsWith("b"))
     );
System.out.println(myMap);

Output:

{1=[Abc, Ab], 3=[Cc]}

Answer 2

As myMap has a lot of members (About 100000) , I don't think the for loop to be such a good idea so I wanna filter

That sounds like you think stream.filter is somehow faster than foreach. It's not; it's either slower or about as fast.

SPOILER: All the way at the end I do some basic performance tests, but I invite anyone to take that test and upgrade it to a full JMH test suite and run it on a variety of hardware. However - it says you're in fact exactly wrong, and foreach is considerably faster than anything involving streams.

Also, it sounds like you feel 100000 is a lot of entries. It mostly isn't. a foreach loop (or rather, an iterator) will be faster. Removing with the iterator will be considerably faster.

parallelism can help you out here, and is simpler with streams, but you can't just slap a parallel() in there and trust that it'll just work out. It depends on the underlying types. For example, your plain jane juHashMap isn't very good at this; Something like a ConcurrentHashMap is far more capable. But if you take the time to copy over all data to a more suitable map type, well, in that timespan you could have done the entire job, and probably faster to boot! (Depends on how large those lists are).

Step 1: Make an oracle

But, first things first, we need an oracle function: One that determines if a given entry ought to be deleted. No matter what solution you go with, this is required:

public boolean keep(List<MyObject> mo) {
    for (MyObject obj : mo) if (obj.specialProperty != null) return true;
    return false;
}

you could 'streamify' it:

public boolean keep(List<MyObject> mo) {
    return mo.stream().anyMatch(o -> o.specialProperty != null);
}

Step 2: Filter the list

Once we have that, the task becomes easier:

var it = map.values().iterator();
while (it.hasNext()) if (!keep(it.next())) it.remove();

is now all you need. We can streamify that if you prefer, but note that you can't use streams to change a map 'in place', and copying over is usually considerably slower, so, this is likely slower and certainly takes more memory:

Map<Integer, List<MyObject>> result =
    map.entrySet().stream()
    .filter(e -> keep(e.getValue()))
    .collect(Collectors.toMap(e -> e.getKey(), e -> e.getValue()));

Note also how the stream option doesn't generally result in significantly shorter code either. Don't make the decision between stream or non-stream based on notions that streams are inherently better, or lead to more readable code. Programming just isn't that simple, I'm afraid.

We can also use some of the more functional methods in map itself:

map.values().removeIf(v -> !keep(v));

That seems like the clear winner, here, although it's a bit bizarre we have to 'bounce' through values() ; map itself has no removeIf method, but the collections returned by keySet, values, entrySet etc reflect any changes back to the map, so that works out.

Let's performance test!

Performance testing is tricky and really requires using JMH for good results. By all means, as an exercise, do just that. But, let's just do a real quick scan:

import java.util.*;
import java.util.stream.*;

public class Test {
    static class MyObj {
        String foo;
    }

    public static MyObj hit() {
        MyObj o = new MyObj();
        o.foo = "";
        return o;
    }

    public static MyObj miss() {
        return new MyObj();
    }

    private static final int MAP_ELEMS = 100000;
    private static final int LIST_ELEMS = 50;
    private static final double HIT_OR_MISS = 0.01;
    private static final Random rnd = new Random();

    public static void main(String[] args) {
        var map = construct();
        long now = System.currentTimeMillis();
        filter_seq(map);
        long delta = System.currentTimeMillis() - now;
        System.out.printf("Sequential: %.3f\n", 0.001 * delta);
        map = construct();
        now = System.currentTimeMillis();
        filter_stream(map);
        delta = System.currentTimeMillis() - now;
        System.out.printf("Stream: %.3f\n", 0.001 * delta);
        map = construct();
        now = System.currentTimeMillis();
        filter_removeIf(map);
        delta = System.currentTimeMillis() - now;
        System.out.printf("RemoveIf: %.3f\n", 0.001 * delta);
    }

    private static Map<Integer, List<MyObj>> construct() {
        var m = new HashMap<Integer, List<MyObj>>();
        for (int i = 0; i < MAP_ELEMS; i++) {
            var list = new ArrayList<MyObj>();
            for (int j = 0; j < LIST_ELEMS; j++) {
                list.add(rnd.nextDouble() < HIT_OR_MISS ? hit() : miss());
            }
            m.put(i, list);
        }
        return m;
    }

    static boolean keep_seq(List<MyObj> list) {
        for (MyObj o : list) if (o.foo != null) return true;
        return false;
    }

    static boolean keep_stream(List<MyObj> list) {
        return list.stream().anyMatch(o -> o.foo != null);
    }

    static void filter_seq(Map<Integer, List<MyObj>> map) {
        var it = map.values().iterator();
        while (it.hasNext()) if (!keep_seq(it.next())) it.remove();
    }

    static void filter_stream(Map<Integer, List<MyObj>> map) {
        Map<Integer, List<MyObj>> result =
            map.entrySet().stream()
            .filter(e -> keep_stream(e.getValue()))
            .collect(Collectors.toMap(e -> e.getKey(), e -> e.getValue()));
    }

    static void filter_removeIf(Map<Integer, List<MyObj>> map) {
        map.values().removeIf(v -> !keep_stream(v));
    }
}

This, reliably, on my hardware anyway, shows that the stream route is by far the slowest, and the sequential option wins out with some percent from the removeIf variant. Which just goes to show that your initial line (if I can take that as 'I think foreach is too slow') was entirely off the mark, fortunately.

For fun I replaced the map with a ConcurrentHashMap and made the stream parallel() . This did not change the timing significantly, and I wasn't really expecting it too.

A note about style

In various snippets, I omit braces for loops and if statements. If you add them, the non-stream-based code occupies considerably more lines, and if you include the indent whitespace for the insides of these constructs, considerably more 'surface area' of paste. However, that is a ridiculous thing to clue off of - that is tantamount to saying: "Actually, the commonly followed style guides for java are incredibly obtuse and badly considered. However, I dare not break them. Fortunately, lambdas came along and gave me an excuse to toss the entire principle of those style guides right out the window and now pile it all into a single, braceless line, and oh look, lambdas lead to shorter code!". I would assume any reader, armed with this knowledge, can easily pierce through such baloney argumentation. The reasons for those braces primarily involve easier debug breakpointing and easy ways to add additional actions to a given 'code node', and those needs are exactly as important, if not more so, if using streams. If it's okay to one-liner and go brace-free for lambdas, then surely it is okay to do the same to if and for bodies.