សំណើ Java ដំណាលគ្នាអាចចែករំលែកការកំណត់ប្រូកស៊ីខុស

thread មួយកំណត់លក្ខណសម្បត្តិប្រូកស៊ី ធ្វើសំណើ ហើយស្តារតម្លៃចាស់វិញ។ thread មួយទៀតធ្វើដូចគ្នាជាមួយប្រូកស៊ីផ្សេង។ កូដមើលទៅរបៀបរៀបរយពេលអានពីលើចុះក្រោម ប៉ុន្តែ thread ទាំងពីរកំពុងផ្លាស់ប្តូរស្ថានភាព JVM ដែលចែករំលែក។

System.setProperty() ផ្លាស់ប្តូរលក្ខណសម្បត្តិប្រព័ន្ធសម្រាប់ដំណើរការ។ វាមិនភ្ជាប់ផ្លូវទៅ thread ដែលបានហៅវាទេ។ សំណើដំណាលគ្នាអាចមើលឃើញតម្លៃដែលសរសេរសម្រាប់ការងាររបស់អ្នកផ្សេង ហើយ client ដែលមានស្រាប់អាចបានចាប់យកការកំណត់របស់ខ្លួនរួចហើយ។

ធ្វើឱ្យផ្លូវជាផ្នែកមួយនៃ client

សម្រាប់ HTTP client របស់ Java សូមបង្កើត client ជាមួយ អ្នកជ្រើសរើសប្រូកស៊ីដែលមានចេតនា។ រក្សា client ដាច់ដោយឡែក នៅពេលការងារត្រូវការគោលនយោបាយផ្លូវខុសគ្នា៖

HttpClient client = HttpClient.newBuilder()
    .proxy(ProxySelector.of(
        new InetSocketAddress("203.0.113.10", 8080)))
    .connectTimeout(Duration.ofSeconds(5))
    .build();

ការនាំចូលគឺ java.net, java.net.http, និង java.time។ អាសយដ្ឋាននេះជាឧទាហរណ៍ សម្រាប់ការសាកល្បងផ្លូវសាធារណៈដែលបានអនុញ្ញាត បញ្ជីប្រូកស៊ី HTTP ផ្តល់ចំណុចចុងក្រោយជាបេក្ខជន។ កំណត់កាលកំណត់សំណើ និង ការផ្ទៀងផ្ទាត់ប្រូកស៊ី ដោយឡែកតាមតម្រូវការរបស់កម្មវិធី។

វិធីសាស្ត្រ proxy របស់ builder កត់ត្រាជម្រើសកម្រិត client។ នោះធ្វើឱ្យគោលនយោបាយងាយពិនិត្យជាងលំដាប់នៃការសរសេរសកលដែលរុំជុំវិញប្រតិបត្តិការអសមកាល។

ការកំណត់សកលនៅតែមានប្រយោជន៍

គោលនយោបាយប្រូកស៊ីតែមួយសម្រាប់ JVM ទាំងមូលអាចសមស្រប នៅពេល client ទាំងអស់ដែលចូលរួមត្រូវបានបម្រុងឱ្យអនុវត្តតាមវា។ កំណត់គោលនយោបាយនោះនៅពេលចាប់ផ្តើមកម្មវិធី ហើយផ្ទៀងផ្ទាត់ថាបណ្ណាល័យណាគោរពតាមវា។

បញ្ហាកើតឡើងនៅពេលលក្ខណសម្បត្តិសកលត្រូវបានប្រើជាកុងតាក់បណ្តោះអាសន្នសម្រាប់សំណើនីមួយៗ។ នៅក្នុងម៉ាស៊ីនមេ កម្មករផ្ទៃខាងក្រោយ និងការហៅបណ្ណាល័យអាចដំណើរការដំណាលគ្នា ទោះបីវិធីសាស្ត្ររបស់អ្នកមើលទៅសមកាលក៏ដោយ។ រក្សាស្ថានភាពផ្លូវជាមួយ client ឬ connector ដែលជាម្ចាស់ការតភ្ជាប់ ដើម្បីកុំឱ្យសំណើផ្សេងអាចផ្លាស់ប្តូរវាពាក់កណ្តាលការងារ។