Stream API — filter, map আর collect দিয়ে ডেটার পাইপলাইন

১ · Stream কী — “কীভাবে” নয়, “কী” লিখুন

একটি অনলাইন দোকানের অর্ডারের তালিকা ভাবুন। মালিক জানতে চান: ঢাকার যেসব অর্ডারের দাম ১,০০০ টাকার বেশি, সেগুলোর পণ্যের নাম, বর্ণানুক্রমে। পর্ব ১১-এর লুপ দিয়ে লিখলে এমন দাঁড়ায়:

List<String> names = new ArrayList<>();
for (Order o : orders) {
    if (o.district().equals("Dhaka") && o.total() > 1000) {
        names.add(o.product());
    }
}
Collections.sort(names);

কোডটি ঠিক আছে, কিন্তু পড়তে হলে মাথায় চালাতে হয়: একটি খালি তালিকা, একটি লুপ, একটি শর্ত, একটি যোগ, শেষে সাজানো। আসল উদ্দেশ্য — “ঢাকার দামি অর্ডারের নাম, সাজানো” — কোডের ভেতরে লুকিয়ে আছে। একই কাজ Stream API দিয়ে:

List<String> names = orders.stream()
    .filter(o -> o.district().equals("Dhaka"))
    .filter(o -> o.total() > 1000)
    .map(Order::product)
    .sorted()
    .toList();

এবার কোডটি প্রায় বাক্যের মতো পড়া যায়: অর্ডারগুলো নাও, ঢাকারগুলো রাখো, দামিগুলো রাখো, পণ্যের নাম নাও, সাজাও, তালিকা বানাও। কোনো খালি তালিকা নেই, কোনো লুপ-ভ্যারিয়েবল নেই, কোনো add নেই। আপনি বলছেন কী চান; কীভাবে ঘুরে ঘুরে করতে হবে, সেটা library-র দায়িত্ব। এই ধাঁচের নাম declarative programming — SQL-এর SELECT … WHERE … ORDER BY ঠিক এমন। আর o -> … হলো পর্ব ৩৪-এর lambda, Order::product একটি method reference — stream-এর প্রতিটি ধাপ একটি functional interface নেয়, তাই এই দুটো ছাড়া stream লেখা যায় না।

একটি pipeline-এর তিন অংশ

তিনটি মিলে একটি stream pipeline. এর তিনটি স্বভাব পুরো পর্ব জুড়ে বারবার আসবে, তাই শুরুতেই মনে গেঁথে নিন:

২ · Stream কোথা থেকে আসে — উৎস

প্রায় যেকোনো ক্রমিক ডেটা থেকেই stream বানানো যায়। সবচেয়ে প্রচলিত উৎসগুলো:

শেষ সারিটি নিয়ে একটি সতর্কতা: Files.lines ফাইলটি খোলা রাখে, তাই একে পর্ব ২৯-এর try-with-resources-এর ভেতরে ব্যবহার করতে হয় — try (Stream<String> lines = Files.lines(path)) { … }. সাধারণ collection-এর stream বন্ধ করার দরকার নেই।

৩ · মাঝের ধাপ — filter, map, flatMap, sorted আর অন্যরা

প্রতিটি মাঝের ধাপ একটি Stream নেয় আর একটি নতুন Stream দেয়। সবচেয়ে বেশি ব্যবহৃত দুটি দিয়ে শুরু:

• filter(শর্ত) — শর্ত সত্য হলে উপাদানটি সামনে যায়, মিথ্যা হলে বাদ। সংখ্যা কমতে পারে, টাইপ একই থাকে। শর্তটি একটি Predicate<T>.
• map(রূপান্তর) — প্রতিটি উপাদানকে অন্য কিছুতে বদলায়: Order থেকে পণ্যের নাম, নাম থেকে বড় হাতের নাম। সংখ্যা একই থাকে, টাইপ বদলাতে পারে (Stream<Order> → Stream<String>). রূপান্তরটি একটি Function<T, R>.
• mapToInt, mapToDouble — map-এর মতোই, কিন্তু ফল সরাসরি int বা double-এর stream; যোগফল আর গড়ের জন্য (অংশ ৭)।

flatMap — তালিকার তালিকা থেকে একটি সমতল তালিকা

ধরুন একটি কোচিং সেন্টারের তিনটি ব্যাচ, প্রতিটি ব্যাচে কয়েকজন শিক্ষার্থী — List<List<String>>. আপনি সব শিক্ষার্থীর একটি তালিকা চান। map(List::stream) দিলে পাবেন তিনটি stream-এর একটি stream — বাক্সের ভেতরে বাক্স। flatMap প্রতিটি ভেতরের বাক্স খুলে উপাদানগুলো একটি লাইনে ঢেলে দেয়:

batches = [ [Rahim, Karim],
            [Ayesha],
            [Sakib, Nusrat] ]
বাইরের তালিকায় ৩টি উপাদান — প্রতিটি নিজেই একটি তালিকা

Stream[ Stream[Rahim, Karim],
        Stream[Ayesha],
        Stream[Sakib, Nusrat] ]
count() → 3   (৫ নয়!)

[Rahim, Karim]   → Rahim, Karim
[Ayesha]         → Ayesha
[Sakib, Nusrat]  → Sakib, Nusrat
একটি লাইনে: Rahim, Karim, Ayesha, Sakib, Nusrat

batches.stream().flatMap(List::stream).toList()
→ [Rahim, Karim, Ayesha, Sakib, Nusrat]
একই কৌশলে লাইন থেকে শব্দ:
lines.stream().flatMap(l -> Arrays.stream(l.split(" ")))

বাকি মাঝের ধাপগুলো

sorted আর distinct একটু আলাদা জাতের। filter বা map প্রতিটি উপাদান একা একা দেখেই সিদ্ধান্ত নেয়। কিন্তু sorted সব উপাদান হাতে না পাওয়া পর্যন্ত বলতে পারে না কোনটা প্রথম, আর distinct-কে আগে দেখা সব মান মনে রাখতে হয়। এদের বলে stateful operation — এরা মেমরি বেশি নেয়, আর অসীম stream-এ sorted কখনো শেষ হয় না।

৪ · অলসতা — উপাদান একে একে পুরো পাইপ পেরোয়

বেশিরভাগ নতুন শিক্ষার্থী stream-কে এভাবে কল্পনা করেন: আগে filter পুরো তালিকায় চলে একটি নতুন তালিকা বানায়, তারপর map সেই তালিকায় চলে আরেকটি তালিকা বানায়, তারপর limit. অর্থাৎ ধাপে ধাপে, “অনুভূমিক”ভাবে। আসলে তা হয় না। Java stream চলে “উল্লম্ব”ভাবে: একটি উপাদান পুরো পাইপ পেরিয়ে যায় (বা মাঝপথে বাদ পড়ে), তারপর পরের উপাদান। আর শেষ ধাপ না আসা পর্যন্ত একটিও না। এর নাম lazy evaluation. নিজে দেখুন — প্রতিটি ধাপে একটি ছাপার লাইন বসানো আছে:

import java.util.List;
class Main {
    public static void main(String[] args) {
        List<String> names = List.of("Rahim", "Ayesha", "Karim", "Nusrat", "Tamim", "Sadia");
        var pipeline = names.stream()
            .filter(n -> { System.out.println("filter: " + n); return n.length() > 5; })
            .map(n -> { System.out.println("  map: " + n); return n.toUpperCase(); })
            .limit(2);
        System.out.println("pipeline তৈরি — এখনো কিছু চলেনি");
        List<String> result = pipeline.toList();      // terminal operation
        System.out.println("ফল: " + result);
        try {
            pipeline.count();                         // দ্বিতীয়বার
        } catch (IllegalStateException e) {
            System.out.println("আবার চালাতে গেলে: " + e.getMessage());
        }
    }
}

এবার একই ঘটনা ধীরে, ধাপে ধাপে:

1names.stream()            // উৎস: ৬টি নাম2  .filter(n -> n.length() > 5)3  .map(String::toUpperCase)4  .limit(2)5  .toList();                // terminal

এই অলসতা থেকে তিনটি বাস্তব লাভ: (ক) একটিমাত্র পাস — মাঝখানে কোনো অস্থায়ী তালিকা তৈরি হয় না; (খ) দরকারের বেশি কাজ নয় — limit, findFirst আগেভাগে থামায়; (গ) অসীম উৎস সম্ভব। তবে ব্যতিক্রম মনে রাখুন: sorted একটি দেয়াল। Stream.of(3, 1, 2).peek(…"before")… .sorted().peek(…"after") চালালে আগে তিনটি before 3, before 1, before 2, তারপর after 1, after 2, after 3 — সাজানোর জন্য সবাইকে আগে জমা হতে হয়।

একবারের স্বভাবের একটি ব্যবহারিক রূপ: stream-কে ভ্যারিয়েবলে রেখে দুবার ব্যবহার করবেন না।

Stream<String> s = Stream.of("Dhaka", "Sylhet");
s.forEach(System.out::println);
s.forEach(System.out::println);       // লাইন ৭

Dhaka
Sylhet
Exception in thread "main" java.lang.IllegalStateException: stream has already been operated upon or closed
	at java.base/java.util.stream.AbstractPipeline.sourceStageSpliterator(AbstractPipeline.java:279)
	at java.base/java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:762)
	at Main.main(Main.java:7)

দরকার হলে stream নয়, উৎসটি (তালিকা) রেখে দিন, অথবা stream দেওয়ার একটি method লিখুন (Supplier<Stream<String>>).

৫ · শেষ ধাপ — ফল বের করা, short-circuit আর reduce

শেষ ধাপ (terminal operation) একটি Stream নয়, আসল ফল দেয় — একটি তালিকা, একটি সংখ্যা, একটি সত্য-মিথ্যা, বা কিছুই না (শুধু কাজ)।

তালিকায় ফেরা — toList() বনাম Collectors.toList()

Java 16 থেকে stream.toList() সরাসরি একটি তালিকা দেয়। এটি একটি unmodifiable collection — তাতে কিছু যোগ করতে গেলে:

List<Integer> marks = Stream.of(72, 28, 91).toList();
marks.add(50);                        // লাইন ৬

Exception in thread "main" java.lang.UnsupportedOperationException
	at java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
	at java.base/java.util.ImmutableCollections$AbstractImmutableCollection.add(ImmutableCollections.java:147)
	at Main.main(Main.java:6)

UnsupportedOperationException-এর কোনো বার্তা নেই, শুধু নাম — তাই চিনে রাখুন। পুরোনো কোডে দেখবেন .collect(Collectors.toList()) (Java 8 থেকে)। বর্তমান JDK-তে এটি একটি ArrayList দেয়, যাতে add চলে — কিন্তু documentation কোনো নির্দিষ্ট টাইপ বা পরিবর্তনযোগ্যতার প্রতিশ্রুতি দেয় না। নিয়ম: শুধু পড়ার জন্য তালিকা চাইলে toList(); পরে বদলাতে চাইলে স্পষ্ট করে .collect(Collectors.toCollection(ArrayList::new)).

গোনা, যোগ, গড় আর খোঁজা

average, max, findFirst কেন সরাসরি সংখ্যা বা object দেয় না? কারণ stream খালি হতে পারে — শূন্যটি নম্বরের গড় কত? কোনো উত্তর নেই। পুরোনো Java হলে null ফেরত দিত আর কোথাও গিয়ে NullPointerException হতো। তার বদলে আসে একটি Optional — “মান থাকতেও পারে, না-ও পারে” লেখা একটি বাক্স। সেটা খোলার নিরাপদ উপায় (orElse, ifPresent, map) পরের পর্ব ৩৬-এর বিষয়; এখানে শুধু মনে রাখুন — findFirst().get() সরাসরি লিখবেন না।

anyMatch, allMatch, noneMatch, findFirst আর limit হলো short-circuiting operation: উত্তর জানা হয়ে গেলেই থামে। anyMatch(s -> s.marks() < 33) প্রথম ফেল-করা শিক্ষার্থী পেলেই true দেয়, বাকিদের দেখে না — ঠিক পর্ব ০৭-এর &&, ||-এর মতো।

reduce — অনেক থেকে এক

sum, count, max — সবই আসলে একটি সাধারণ ধারণার বিশেষ রূপ: অনেকগুলো উপাদানকে একটি নিয়মে বারবার জুড়ে একটি ফলে নামিয়ে আনা। একে বলে reduction, আর সাধারণ রূপটি হলো reduce(শুরুর মান, জোড়ার নিয়ম). পর্ব ১১-এর accumulator লুপের কথা মনে করুন — int total = 0; for (...) total += p; — reduce ঠিক সেটাই, শুধু লুপটা library চালায়:

1List<Integer> prices = List.of(120, 80, 250, 50);2int total = prices.stream()3    .reduce(0, (acc, p) -> acc + p);4System.out.println(total);

একটি শর্ত: জোড়ার নিয়মটি associative হতে হবে — (a + b) + c আর a + (b + c) একই ফল দিতে হবে — আর identity সত্যিই নিরপেক্ষ হতে হবে। যোগ, গুণ, max ঠিক আছে; বিয়োগ নয়। Sequential stream-এ ভুলটা চোখে পড়ে না, কিন্তু parallel stream টুকরোগুলো যেকোনো ক্রমে জোড়ে, তখন ভুল ফল আসে।

৬ · Collectors — দলে ভাগ, গোনা আর Map বানানো

collect(...) একটি সাধারণ শেষ ধাপ, যাকে বলে দিতে হয় উপাদানগুলো কীভাবে জমাতে হবে। সেই রেসিপিকে বলে collector, আর java.util.stream.Collectors class-এ তৈরি রেসিপির একটি ভাণ্ডার আছে:

• toSet() — পুনরাবৃত্তিহীন সেট (ক্রমের নিশ্চয়তা নেই)।
• joining(", ", "[", "]") — String-গুলো জোড়া: [Rahim, Karim, Ayesha, Sakib, Nusrat]. বিভাজক, শুরু আর শেষের চিহ্ন ঐচ্ছিক।
• toMap(keyফাংশন, valueফাংশন) — প্রতিটি উপাদান থেকে একটি key-value জোড়া।
• groupingBy, partitioningBy, teeing — নিচে বিস্তারিত।

toMap-এর ফাঁদ — একই key দুবার

জেলা থেকে বিক্রির পরিমাণের Map বানাতে চাইলেন, কিন্তু ঢাকার দুটি সারি আছে:

List<Row> rows = List.of(new Row("a", "Dhaka", 10), new Row("b", "Sylhet", 5),
                         new Row("c", "Dhaka", 7));
Map<String, Integer> m = rows.stream()
    .collect(Collectors.toMap(Row::district, Row::amount));    // লাইন ৭

Exception in thread "main" java.lang.IllegalStateException: Duplicate key Dhaka (attempted merging values 10 and 7)
	at java.base/java.util.stream.Collectors.duplicateKeyException(Collectors.java:135)
	…
	at Main.main(Main.java:7)

বার্তাটি স্পষ্ট: key Dhaka দুবার এসেছে, মান 10 আর 7 — কোনটা রাখব? এটা ভালো আচরণ; নীরবে একটি মান হারালে বিক্রির হিসাব ভুল হতো। সমাধান তৃতীয় argument — merge function, যা বলে দুটি মান কীভাবে মেলাতে হবে; চতুর্থ argument দিয়ে সাজানো Map: toMap(Row::district, Row::amount, Integer::sum, TreeMap::new) → {Dhaka=17, Sylhet=5}.

groupingBy — দলে ভাগ করা

“জেলাভিত্তিক অর্ডারের সংখ্যা” — SQL-এর GROUP BY. groupingBy তিনটি জিনিস নিতে পারে: কোন key দিয়ে ভাগ করবে, কোন ধরনের Map বানাবে, আর প্রতিটি দলের উপাদান নিয়ে কী করবে। শেষেরটিকে বলে downstream collector. শুধু key দিলে দুটি জিনিস ডিফল্ট হয়: প্রতিটি দলে একটি List, আর Map হয় একটি HashMap — যার ছাপার ক্রম অনিশ্চিত। নির্দিষ্ট, বর্ণানুক্রমিক আউটপুট চাইলে TreeMap চেয়ে নিন:

1orders.stream()2  .collect(groupingBy(Order::district,   // key3                      TreeMap::new,      // সাজানো Map4                      counting()));      // প্রতি দলে কী

Downstream collector-এর আরও কয়েকটি, একই CSV-ধাঁচের ডেটায় (Rahim–Dhaka–1500, Karim–Sylhet–900, Ayesha–Dhaka–2100):

এবার সব মিলিয়ে একটি দোকানের আসল হিসাব — মোট বিক্রি, সবচেয়ে বেশি আয় এনেছে এমন ৩টি পণ্য, আর জেলাভিত্তিক অর্ডার। চালিয়ে দেখুন:

import java.util.*;
import java.util.stream.Collectors;
record Order(String product, String district, int qty, int price) { int total() { return qty * price; } }
class Main {
    public static void main(String[] args) {
        List<Order> orders = List.of(
            new Order("Panjabi", "Dhaka", 2, 1500), new Order("Saree", "Chattogram", 1, 3200),
            new Order("Panjabi", "Sylhet", 1, 1500), new Order("Lungi", "Dhaka", 3, 450),
            new Order("Saree", "Dhaka", 1, 3200), new Order("Tea", "Sylhet", 5, 300));
        int revenue = orders.stream().mapToInt(Order::total).sum();
        System.out.println("মোট বিক্রি: " + revenue + " টাকা");
        Map<String, Integer> byProduct = orders.stream()
            .collect(Collectors.groupingBy(Order::product, Collectors.summingInt(Order::total)));
        List<String> top3 = byProduct.entrySet().stream()
            .sorted(Map.Entry.<String, Integer>comparingByValue().reversed())
            .limit(3).map(Map.Entry::getKey).toList();
        System.out.println("সেরা ৩ পণ্য: " + top3);
        Map<String, Long> perDistrict = orders.stream()
            .collect(Collectors.groupingBy(Order::district, TreeMap::new, Collectors.counting()));
        System.out.println("জেলাভিত্তিক অর্ডার: " + perDistrict);
    }
}

partitioningBy — দুই ভাগ: পাস আর ফেল

ভাগ যখন মাত্র দুটি — শর্ত সত্য আর মিথ্যা — তখন partitioningBy. ফল সবসময় Map<Boolean, …>, যার দুটি key-ই থাকে, এমনকি কোনো দল খালি হলেও। নম্বর Rahim 72, Karim 28, Ayesha 91, Sakib 33, Nusrat 39; পাস নম্বর 33:

Map<Boolean, List<String>> result = students.stream()
    .collect(Collectors.partitioningBy(s -> s.marks() >= 33,
             Collectors.mapping(Student::name, Collectors.toList())));
// {false=[Karim], true=[Rahim, Ayesha, Sakib, Nusrat]}
// counting() দিলে: {false=1, true=4}

বাংলা লেখায় শব্দের গণনা

flatMap আর groupingBy একসাথে — একটি লেখার কোন শব্দ কতবার এসেছে। Search engine, spell checker আর ভাষা-মডেলের প্রাথমিক ধাপ এমন গণনা দিয়েই শুরু হয়:

String text = "আমি ভাত খাই আমি চা খাই সে চা খায় আমি";
Map<String, Long> freq = Arrays.stream(text.split("\\s+"))
    .collect(Collectors.groupingBy(w -> w, TreeMap::new, Collectors.counting()));
System.out.println(freq);
// {আমি=3, খাই=2, খায়=1, চা=2, ভাত=1, সে=1}

split("\\s+") এক বা একাধিক ফাঁকা জায়গায় ভাঙে। TreeMap বাংলা শব্দগুলো Unicode-এর অক্ষর-ক্রমে সাজায় — অভিধানের ক্রমের কাছাকাছি, তবে হুবহু নয়। অনেক লাইনের লেখা হলে আগে lines().flatMap(l -> Arrays.stream(l.split("\\s+"))).

CSV লাইন থেকে record

পর্ব ২৫-এর record আর stream মিলে ছোট ডেটা-পার্সার:

String csv = """
    Rahim,Dhaka,1500
    Karim,Sylhet,900
    Ayesha,Dhaka,2100
    """;
List<Row> rows = csv.lines()
    .map(line -> line.split(","))
    .map(p -> new Row(p[0], p[1], Integer.parseInt(p[2])))
    .toList();
// [Row[name=Rahim, district=Dhaka, amount=1500], Row[name=Karim, ...], ...]

বাস্তব CSV-তে কমার ভেতরে কমা, উদ্ধৃতিচিহ্ন বা ফাঁকা লাইন থাকে; তখন একটি CSV library ব্যবহার করুন। ধারণাটি একই থাকে: লাইন → টুকরো → object.

teeing — এক পাসে দুটি হিসাব (Java 12 থেকে)

Collectors.teeing(c1, c2, মেলানো) একই উপাদানগুলো দুটি collector-কে একসাথে পাঠায়, তারপর দুটি ফল মেলায় — যেমন সর্বনিম্ন আর সর্বোচ্চ একসাথে: teeing(minBy(cmp), maxBy(cmp), (mn, mx) -> mn.get() + ".." + mx.get()) নম্বর 72, 28, 91, 33-এর জন্য দেয় 28..91. নামটি সম্ভবত Unix-এর tee কমান্ডের (বা ইংরেজি T আকৃতির পাইপ-জোড়ার) কথা মনে করিয়ে দিতে রাখা — tee একটি প্রবাহকে দুই দিকে পাঠায়। কম ব্যবহৃত, কিন্তু চিনে রাখা ভালো।

৭ · ফাঁদ — boxing, side effect আর parallel

Primitive stream — boxing এড়ান

Stream<Integer>-এর প্রতিটি উপাদান একটি আলাদা Integer object (পর্ব ০৬-এর autoboxing). কয়েক লাখ সংখ্যার যোগে প্রতিবার boxing-unboxing আর heap-এ নতুন object — অকারণ খরচ। তাই Java-তে তিনটি primitive stream আছে: IntStream, LongStream, DoubleStream. এগুলো সরাসরি int, long, double বয়ে নেয়, আর এদের আছে সংখ্যার বিশেষ method: sum(), average(), max(), আর summaryStatistics() — এক পাসে সব: IntSummaryStatistics{count=5, sum=263, min=28, average=52.600000, max=91}.

• object → সংখ্যা: mapToInt(Student::marks), mapToDouble(...)
• সংখ্যা → object: boxed() — যেমন IntStream.range(1, 5).boxed().toList() দেয় [1, 2, 3, 4]
• Stream<Integer>-এ সরাসরি sum() নেই — সাধারণ object-এর stream-এ “যোগ” অর্থহীন, তাই আগে mapToInt.

Side effect — stream-এর ভেতর থেকে বাইরের জিনিস বদলাবেন না

লুপের অভ্যাসে অনেকে এভাবে লেখেন:

List<Integer> evens = new ArrayList<>();
IntStream.rangeClosed(1, 10)
    .filter(x -> x % 2 == 0)
    .forEach(evens::add);          // বাইরের তালিকা বদলানো — এড়ান

এটি চলে ([2, 4, 6, 8, 10]), কিন্তু এটা stream-এর ছদ্মবেশে একটি লুপ। বাইরের ভ্যারিয়েবল বদলানোকে বলে side effect. Stream-এর নকশা ধরে নেয় যে প্রতিটি ধাপের lambda একটি pure method-এর মতো: শুধু argument দেখে ফল দেয়, বাইরের কিছু বদলায় না। কারণ তিনটি:

1. Parallel করলে ভাঙে। কেউ পরে .parallel() জুড়ে দিলে একাধিক thread একসাথে একটি সাধারণ ArrayList-এ add করবে। ArrayList thread-safe নয় — উপাদান হারাতে পারে, ক্রম এলোমেলো হয়, এমনকি ArrayIndexOutOfBoundsException. প্রতিবার আলাদা ফল, তাই bug ধরাও কঠিন।
2. চলবে কি না, তারও নিশ্চয়তা নেই। JDK-র stream অপ্রয়োজনীয় কাজ বাদ দিতে পারে। যেমন Java 9 থেকে উৎসের আকার জানা থাকলে count() পুরো pipeline চালায়ই না: Stream.of("a", "b", "c").map(s -> { System.out.println("map " + s); return s; }).count() ছাপে শুধু 3 — একটিও “map” লাইন নয়। map বা peek-এর ভেতরের side effect-এর ওপর ভরসা করা কোড এভাবে নীরবে ভেঙে যায়।
3. পড়ার সুবিধা হারায়। Stream-এর মূল প্রতিশ্রুতি ছিল “কী চাই” লেখা। বাইরের তালিকা ভরানো আবার “কীভাবে”-তে ফিরে যাওয়া।

সঠিক রূপ: ফলটা stream নিজেই বানাক — List<Integer> evens = IntStream.rangeClosed(1, 10).filter(x -> x % 2 == 0).boxed().toList();. forEach রাখুন শেষ কাজের জন্য — ছাপা, লগ লেখা, পাঠানো। আর peek শুধু debug-এর সময় সাময়িকভাবে।

Parallel stream — এক লাইনে, কিন্তু ভেবেচিন্তে

orders.parallelStream() বা .parallel() লিখলেই কাজ ভাগ হয়ে একাধিক CPU core-এ চলে — এটাই parallel stream. শুনতে জাদুর মতো, কিন্তু বাস্তবে প্রায়ই ধীর বা ভুল: উৎসকে টুকরো করা, thread-এ পাঠানো আর ফল জোড়ার একটা খরচ আছে, যা ছোট ডেটায় লাভের চেয়ে বেশি। LinkedList বা Stream.iterate-এর মতো উৎস ভালোভাবে ভাগ হয় না; limit, findFirst, forEachOrdered-এর মতো ক্রম-নির্ভর ধাপ parallel-এ ব্যয়বহুল; আর ওপরের side effect সরাসরি ভুল ফল দেয়। Parallel stream ডিফল্টে সব প্রোগ্রামের ভাগাভাগি করা একটি thread pool ব্যবহার করে, তাই তার ভেতরে ধীর নেটওয়ার্ক বা ডেটাবেস কল দিলে অন্য কাজও আটকে যায়। নিয়ম: আগে sequential, তারপর মেপে দেখুন (benchmark); বড় ডেটা, প্রতি উপাদানে ভারী হিসাব, স্বাধীন কাজ আর ভালোভাবে ভাগ হয় এমন উৎস (ArrayList, array, IntStream.range) — চারটি একসাথে থাকলে তবেই ভাবুন। Thread, synchronization আর executor-এর ভিত্তি পর্ব ৪০–৪২-এ।

৮ · লুপ না stream? — পড়ার সুবিধা, পারফরম্যান্স আর বিচারবুদ্ধি

Stream লুপের বদলি নয়, একটি বিকল্প। লুপে লুপ চালানোর দায়িত্ব আপনার — একে বলে external iteration; stream-এ সেই দায়িত্ব library-র — internal iteration. কোনটা কখন ভালো, তার একটি ব্যবহারিক হিসাব:

Checked exception-এর সমস্যাটা দেখুন। প্রতিটি ফাইল পড়তে চাইলেন:

List<String> texts = files.stream()
    .map(f -> Files.readString(Path.of(f)))     // লাইন ৮
    .toList();

Main.java:8: error: unreported exception IOException; must be caught or declared to be thrown
            .map(f -> Files.readString(Path.of(f)))
                                      ^
1 error

map নেয় একটি Function, যার apply method কোনো checked exception ঘোষণা করে না — তাই পুরো method-এ throws IOException লিখলেও lambda-র ভেতরে চলে না। উপায় হলো lambda-র ভেতরে try-catch দিয়ে unchecked exception-এ মুড়ে দেওয়া, বা ছোট একটি সাহায্যকারী method লেখা; তিন-চার লাইনের কাজে একটি সাধারণ for লুপ প্রায়ই বেশি পরিষ্কার।

পারফরম্যান্স — সংক্ষেপে সত্যিটা

• ছোট থেকে মাঝারি ডেটায় stream আর লুপের গতির পার্থক্য সাধারণত নগণ্য; JIT দুটোকেই ভালোভাবে অপ্টিমাইজ করে। খুব গরম, ছোট লুপে (কনটেস্ট, সংখ্যা-গণনা) হাতে লেখা লুপ বা int[] একটু দ্রুত হতে পারে — সন্দেহ হলে মাপুন।
• বড় খরচ সাধারণত আসে boxing (Stream<Integer>), অপ্রয়োজনীয় sorted, আর একই তালিকায় বারবার নতুন stream চালানো থেকে — একটি লুপে যা এক পাসে হয়, তা পাঁচটি আলাদা stream-এ পাঁচ পাস।
• অলসতা আর short-circuit-এর কারণে filter আগে, ভারী map পরে, আর limit যত আগে সম্ভব — এতে কাজ কমে।
• সবচেয়ে বড় লাভ গতিতে নয়, পড়ায়: একজন সহকর্মী (বা ছয় মাস পরের আপনি) কত তাড়াতাড়ি বুঝবেন কোডটি কী করছে।

৯ · AI-এর যুগে — লম্বা শিকল আর অন্ধ parallel()

AI stream খুব পছন্দ করে — দেখতে আধুনিক লাগে, আর এক লাইনে অনেক কাজ। সমস্যা হলো, “এক লাইনে অনেক কাজ” আর “পরিষ্কার কোড” এক জিনিস নয়। AI-এর লেখা Java stream কোডে বারবার যে ভুলগুলো আসে:

AI-এর stream কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি শিকল জোরে পড়লে একটি বাক্যের মতো শোনায়; কোনো শিকল এক স্ক্রিনের বেশি নয়
• কোনো forEach, map বা peek বাইরের collection বা ভ্যারিয়েবল বদলাচ্ছে না
• কোথাও .parallel() থাকলে তার পাশে মাপা প্রমাণ আছে, আর ভেতরে কোনো shared state নেই
• findFirst, max, min, average-এর ফল খালি হলে কী হবে, তা কোডে সামলানো
• toMap-এ duplicate key-এর সম্ভাবনা ভেবে দেখেছি; ছাপা Map-এর ক্রম নির্দিষ্ট
• সংখ্যার হিসাবে mapToInt/IntStream, অকারণ Stream<Integer> নয়
• যেখানে লুপ বেশি পরিষ্কার (মাঝপথে থামা, checked exception, পাশের উপাদানের তুলনা), সেখানে লুপই আছে