Thread Pool sa mobile development — mga batayan, thread pool at prinsipyo ng paggana

Ano ang Thread Pool?

Thread Pool (pool ng thread) — ay isang architectural pattern kung saan ang isang nakapirming bilang ng mga thread ay ginagawa nang maaga at muling ginagamit upang magsagawa ng maraming gawain. Sa halip na lumikha ng bagong thread para sa bawat operasyon (na mahal: mga 1 MB ng stack bawat thread sa JVM), ang mga gawain ay inilalagay sa isang queue at isinasagawa ng mga libreng thread mula sa pool. Sa mobile development, ang thread pool ay kritikal para sa pagganap — nililimitahan ng Android at iOS ang bilang ng mga thread bawat app.

Bakit mahalaga ang Thread Pool sa mobile development

Ang paglikha ng thread ay isang mahal na operasyon: paglalaan ng stack, pagpaparehistro sa system, paglipat ng konteksto. Sa mga mobile device na may limitadong resources, ang hindi kontroladong paglikha ng thread ay humahantong sa OOM (OutOfMemoryError) sa Android at throttling sa iOS. Thread Pool ay lumulutas ng parehong problema: nililimitahan ang maximum na bilang ng sabay na tumatakbong thread at muling ginagamit ang mga nagawa nang thread. Inirerekomenda ng Google ang ExecutorService sa halip na raw Thread(), inirerekomenda ng Apple ang OperationQueue sa halip na Thread.

Paano gumagana ang Thread Pool sa mobile development?

Ang thread pool ay gumagana sa prinsipyong Producer-Consumer: ang mga gawain (Runnable/Callable) ay inilalagay sa isang naka-block na queue (BlockingQueue). Ang mga thread mula sa pool ay naghihintay ng mga gawain sa queue at kinukuha ang mga ito para isagawa. Algoritmo: kung mas kaunti ang libreng thread kaysa corePoolSize, isang bagong thread ang ginagawa. Kung naabot na ang corePoolSize, ang gawain ay inilalagay sa queue. Kung puno ang queue at mas kaunti ang thread kaysa maximumPoolSize, isang karagdagang thread ang ginagawa. Kapag nalampasan ang maximumPoolSize, ang gawain ay tinatanggihan sa pamamagitan ng RejectedExecutionHandler.

Core Pool Size vs Maximum Pool Size

Core pool size — ang bilang ng mga thread na pinananatili sa pool kahit na idle. Maximum pool size — ang maximum na bilang ng mga thread na maaaring gawin kapag umapaw ang queue. Ang pagkakaiba sa pagitan ng mga ito ay mga karagdagang (overflow) thread na ginagawa pansamantala at tinatapos pagkatapos ng idle timeout. Sa mga mobile device, inirerekomenda na itakda ang corePoolSize na katumbas ng maximumPoolSize upang maiwasan ang peak load sa paggawa ng thread.

Work Queue at RejectedExecutionHandler

BlockingQueue ay nag-iimbak ng mga gawaing naghihintay ng execution. Ang pinakasikat na implementasyon: LinkedBlockingQueue (walang limitasyon), ArrayBlockingQueue (may limitasyon) at SynchronousQueue (walang storage — ang gawain ay agad na ipinapasa sa thread). Kapag umapaw ang queue at pool, RejectedExecutionHandler ay isinaaktibo. Mga karaniwang patakaran: AbortPolicy (nagtatapon ng RejectedExecutionException), CallerRunsPolicy (nagsasagawa sa thread ng nagpadala), DiscardPolicy at DiscardOldestPolicy.

// Paglikha ng Thread Pool sa Android
val threadPool = ThreadPoolExecutor(
    corePoolSize = 2,        // Minimum na 2 thread
    maximumPoolSize = 4,     // Maximum na 4 thread
    keepAliveTime = 30L,     // Buhay ng overflow thread
    unit = TimeUnit.SECONDS,
    workQueue = LinkedBlockingQueue<Runnable>(16),
    threadFactory = Executors.defaultThreadFactory(),
    handler = ThreadPoolExecutor.CallerRunsPolicy()
)

// Pagpapadala ng mga gawain
threadPool.execute {
    val result = api.fetchData()
    runOnUiThread { showData(result) }
}

// Pagsasara ng pool
threadPool.shutdown()
// Pag-antay sa pagkumpleto ng lahat ng gawain
threadPool.awaitTermination(10, TimeUnit.SECONDS)

Thread Pool sa Android: ExecutorService

Ang Android ay nagbibigay ng ilang implementasyon ng thread pool sa pamamagitan ng java.util.concurrent. Executors — isang pabrika na may mga handa nang configuration: newFixedThreadPool(n) (fixed pool), newCachedThreadPool() (walang limitasyon, ang mga thread ay ginagawa kung kinakailangan), newSingleThreadExecutor() (isang thread — sequential execution). Para sa mga mobile project, inirerekomenda ang newFixedThreadPool na may makatwirang limitasyon (2-4 thread), dahil ang cached pool ay maaaring lumikha ng masyadong maraming thread.

ThreadPoolExecutor sa Android

ThreadPoolExecutor (TPE) — ang kumpletong implementasyon ng ExecutorService na may mga configurable na parameter. Sa Android, ang TPE ay ginagamit sa loob ng AsyncTask, IntentService at JobIntentService. Ang mga parameter na corePoolSize, maximumPoolSize, keepAliveTime, BlockingQueue at RejectedExecutionHandler ay nagpapahintulot ng fine-tuning ng pag-uugali ng pool. Mga rekomendasyon para sa Android: corePoolSize = bilang ng CPU cores - 1 (para sa IO-bound tasks) o bilang ng cores (para sa CPU-bound tasks). Para sa mga tipikal na app — 2-4 thread.

// Mga handa na configuration ng Executors
// 1. Fixed pool para sa 3 thread
val fixedPool = Executors.newFixedThreadPool(3)

// 2. Naka-cache na pool (hindi inirerekomenda para sa mobile)
val cachedPool = Executors.newCachedThreadPool()

// 3. Nag-iisang thread (serialization)
val singlePool = Executors.newSingleThreadExecutor()

// 4. Scheduler (pana-panahong mga gawain)
val scheduler = Executors.newScheduledThreadPool(2)

// Paggamit sa Callable at Future
val future: Future<String> = fixedPool.submit(Callable {
    "Result: ${api.call()}"
})
// Pagkuha ng resulta (binablock ang thread)
val result = future.get(5, TimeUnit.SECONDS)

// Pagsasara ng pool
fixedPool.shutdownNow()

CoroutineDispatcher bilang thread pool

Ang Kotlin coroutine ay nagbibigay ng CoroutineDispatcher — isang abstraction na katulad ng thread pool. Ang Dispatchers.IO ay gumagamit ng pool ng 64 thread (limitado). Ang Dispatchers.Default — pool na katumbas ng bilang ng CPU cores. Ang CoroutineDispatcher ay hindi nangangailangan ng manual shutdown at awtomatikong pinamamahalaan. Para sa fine-tuning, gumawa ng sarili mong ExecutorCoroutineDispatcher sa pamamagitan ng Executors.newFixedThreadPool(2).asCoroutineDispatcher(). Ang mga coroutine ay hindi pumapalit sa thread pool, kundi binabalot ito.

Thread Pool sa iOS: OperationQueue at GCD

Ang iOS ay nagbibigay ng dalawang pangunahing mekanismo para sa pamamahala ng thread pool: OperationQueue (high-level API batay sa GCD) at GCD DispatchQueue (low-level C-API). Ang OperationQueue ay nag-eencapsulate ng thread pool sa pamamagitan ng property na maxConcurrentOperationCount. Bilang default, ang OperationQueue ay gumagamit ng system-defined maximum (depende sa load ng system). Ang DispatchQueue.global() ay nagbibigay ng concurrent queue na may system thread pool.

OperationQueue at maxConcurrentOperationCount

OperationQueue ay namamahala ng thread pool sa pamamagitan ng maxConcurrentOperationCount. Ang value na 1 ay gumagawa ng serial queue (katulad ng single thread pool). Ang value na higit sa 1 — concurrent pool na may tinukoy na limitasyon. Bilang default, maxConcurrentOperationCount = NSOperationQueueDefaultMaxConcurrentOperationCount (system optimum, karaniwang 4-8 thread). Ang Operation ay sumusuporta sa mga dependency, priority at pagkansela. Ang bawat operasyon ay isinasagawa sa anumang libreng thread mula sa system pool.

// OperationQueue na may pool ng 3 thread
let queue = OperationQueue()
queue.maxConcurrentOperationCount = 3
queue.qualityOfService = .utility

// Paglikha ng mga operasyon
let operation1 = BlockOperation {
    let data = fetchData(from: url1)
    DispatchQueue.main.async { updateUI(data) }
}

let operation2 = BlockOperation {
    let data = fetchData(from: url2)
    DispatchQueue.main.async { updateUI(data) }
}

// Dependency: operation2 naghihintay sa operation1
operation2.addDependency(operation1)

// Pagdagdag sa queue
queue.addOperations([operation1, operation2], waitUntilFinished: false)

// Pagkansela ng lahat ng operasyon
queue.cancelAllOperations()

GCD DispatchQueue bilang thread pool

DispatchQueue — ang thread pool mula sa Apple. Ang concurrent queue (qos: .utility) ay gumagamit ng system thread pool, na optimize para sa kasalukuyang load ng device. Ang iba't ibang QoS (userInteractive, userInitiated, utility, background) ay na-map sa iba't ibang pool na may iba't ibang priority. DispatchGroup ay nagpapahintulot ng synchronization ng maraming gawain. Ang DispatchWorkItem ay sumusuporta sa pagkansela at qualityOfService. Para sa fine control, gumawa ng sarili mong concurrent queue sa pamamagitan ng DispatchQueue(label: qos: attributes: .concurrent).

// GCD DispatchQueue bilang thread pool
let customQueue = DispatchQueue(
    label: "com.app.background",
    qos: .utility,
    attributes: .concurrent,
    autoreleaseFrequency: .workItem
)

// Pagpapadala ng mga gawain sa pool
customQueue.async { self.processFile(file1) }
customQueue.async { self.processFile(file2) }

// DispatchGroup para sa synchronization
let group = DispatchGroup()
let pool = DispatchQueue.global(qos: .utility)

pool.async(group: group) { fetchData() }
pool.async(group: group) { processImage() }

group.notify(queue: .main) {
    self.showResult() // Parehong gawain ay natapos
}

// Paglimit ng concurrency sa pamamagitan ng semaphore
let semaphore = DispatchSemaphore(value: 3)
for url in urls {
    pool.async {
        semaphore.wait()
        download(url)
        semaphore.signal()
    }
}

Mga parameter ng configuration ng Thread Pool

Ang configuration ng thread pool ay direktang nakakaapekto sa pagganap ng app. Mga maling parameter ay humahantong sa hindi sapat na paggamit ng CPU (sobrang kaunting thread) o overload ng system (sobrang daming thread). Sa mga mobile app, ang optimal na mga value ay naiiba sa server values dahil sa limitadong resources at pagkonsumo ng kuryente. Mga pangunahing parameter: corePoolSize, maxPoolSize, queue capacity at keepAliveTime.

Pagkalkula ng optimal na laki ng pool

Formula para sa IO-bound tasks: corePoolSize = bilang ng CPU cores × 2 (naghihintay ang mga thread ng input-output). Para sa CPU-bound tasks: corePoolSize = bilang ng CPU cores (ang mga thread ay palaging abala sa pag-compute). Sa modernong mobile device (6-8 cores), ito ay nagbibigay ng 6-8 thread para sa CPU-bound at 12-16 para sa IO-bound. Ipinapakita ng practical na mga test na para sa tipikal na mobile app, 3-4 thread ay optimal — mas maraming thread ay nagpapataas ng pagkonsumo ng kuryente nang walang pagtaas ng pagganap.

Queue Capacity at pag-uugali sa pag-apaw

Ang laki ng task queue (work queue) ay tumutukoy kung ilang gawain ang maaaring maghintay ng execution. Walang limitasyong queue (LinkedBlockingQueue na walang limitasyon) ay maaaring humantong sa OOM sa mabilis na pagdating ng mga gawain. Limitadong queue (ArrayBlockingQueue na may nakapirming laki) ay tumatanggi sa mga gawain sa pag-apaw. Para sa mga mobile app, inirerekomenda ang ArrayBlockingQueue na may kapasidad na 16-32 gawain. CallerRunsPolicy — ang pinakamahusay na RejectedExecutionHandler para sa mga mobile device: pinapabagal ang nagpadala (pressure back) sa halip na mawala ang gawain.

Mga karaniwang pagkakamali sa pagtatrabaho sa thread pool

Ang mga developer ng mobile app ay madalas na nagkakamali sa paggamit ng thread pool, na humahantong sa pag-crash, pagtagas ng memorya at hindi matatag na operasyon. Pinakakaraniwan: hindi pagtawag ng shutdown() para sa ExecutorService, paggawa ng bagong pool para sa bawat operasyon, masyadong malaking pool, deadlock sa pagitan ng mga gawain, paggamit ng CachedThreadPool sa Android.

Deadlock sa Thread Pool

Ang deadlock ay nangyayari kapag ang isang gawain sa pool ay naghihintay ng resulta ng isa pang gawain mula sa parehong pool, ngunit lahat ng thread ay abala sa paghihintay. Halimbawa: ang gawain A ay nagpapadala ng gawain B sa parehong pool at tumatawag ng future.get() — kung ang pool ay naubos, ang gawain A ay naghihintay ng gawain B, at ang gawain B ay hindi maisasagawa dahil walang libreng thread. Solusyon: gumamit ng hiwalay na pool para sa iba't ibang antas ng gawain o async callback sa halip na .get() na humaharang.

// Deadlock sa Thread Pool
val pool = Executors.newFixedThreadPool(1)

// Gawain A naghihintay sa gawain B — deadlock!
val futureA = pool.submit {
    // Ang gawaing ito ay hindi kailanman maisasagawa
    val futureB = pool.submit { 42 }
    futureB.get() // Naka-block magpakailanman
}

// Pag-aayos: hiwalay na mga pool
val workerPool = Executors.newFixedThreadPool(2)
val callbackPool = Executors.newSingleThreadExecutor()

workerPool.submit {
    callbackPool.submit {
        // Isinasagawa sa hiwalay na pool — deadlock imposible
    }
}

// O gumamit ng CompletableFuture
workerPool.submit {
    CompletableFuture
        .supplyAsync { 42 }
        .thenAccept { result ->
            println(result)
        }
}

Hindi natapos na pool at pagtagas

Ang ExecutorService na ginawa sa Activity ay dapat tapusin sa onDestroy(). Kung hindi ito gagawin, ang mga thread ay mananatili sa memorya kahit na pagkatapos ng pagkasira ng Activity. Solusyon: itago ang pool sa Application scope o ViewModel, hindi sa Activity. Para sa coroutine, gumamit ng viewModelScope o lifecycleScope. Kung ang pool ay ginawa sa loob ng Activity, tiyaking tawagan ang pool.shutdown() sa onDestroy(). Para sa pagsubok, gumamit ng es.shutdownNow() para sa agarang paghinto.