Skyframe StateMachines का इस्तेमाल करने के लिए गाइड

समस्या की शिकायत करें सोर्स देखें

खास जानकारी

Skyframe StateMachine एक डिकोड किया गया फ़ंक्शन-ऑब्जेक्ट है, जो हीप पर मौजूद होता है. जब ज़रूरी वैल्यू तुरंत उपलब्ध नहीं होती, लेकिन उनका एसिंक्रोनस तरीके से आकलन किया जाता है, तो यह सुविधा1 बिना किसी अतिरिक्त शर्त के काम करती है और आकलन करती है. इंतज़ार करते समय, StateMachine, थ्रेड रिसॉर्स को टाई अप नहीं कर सकता. इसके बजाय, इसे निलंबित करके फिर से शुरू करना होगा. इस तरह डिकंस्ट्रक्शन, साफ़ तौर पर री-एंट्री पॉइंट दिखाता है, ताकि पहले के कंप्यूटेशन को स्किप किया जा सके.

StateMachine का इस्तेमाल क्रम, ब्रांचिंग, स्ट्रक्चर्ड लॉजिकल कॉन करंसी को दिखाने के लिए किया जा सकता है. साथ ही, इन्हें खास तौर पर Skyframe इंटरैक्शन के लिए तैयार किया जा सकता है. StateMachine को बड़े StateMachines में बनाया जा सकता है और सब-StateMachine को शेयर किया जा सकता है. निर्माण के आधार पर कॉन करंसी हमेशा पदानुक्रमिक होती है और यह पूरी तरह लॉजिकल होती है. हर एक साथ सभी सबटास्क, शेयर किए गए एक ही SkyFunction थ्रेड में चलता है.

शुरुआती जानकारी

इस सेक्शन में, java.com.google.devtools.build.skyframe.state पैकेज में मौजूद StateMachine के बारे में कम शब्दों में बताया गया है.

Skyframe के रीस्टार्ट होने के बारे में जानकारी

Skyframe एक फ़्रेमवर्क है, जो डिपेंडेंसी ग्राफ़ की पैरलल इवैलुएशन करता है. ग्राफ़ का हर नोड SkyFunction के मूल्यांकन के साथ मेल खाता है जिसमें SkyKey अपने पैरामीटर तय करती है और SkyValue उसका नतीजा बताता है. कंप्यूटेशनल मॉडल ऐसा है कि SkyFunction, SkyKey से SkyValues को ढूंढ सकता है. इससे अतिरिक्त SkyFunctions का बार-बार होने वाला आकलन ट्रिगर होता है. अगर कंप्यूटेशन के कुछ सबग्राफ़ के अधूरे होने की वजह से कंप्यूटेशन के कुछ सबग्राफ़ अधूरे हैं, तो ब्लॉक करने के बजाय, थ्रेड को बाँधना होता है. ऐसे में, अनुरोध करने वाले SkyFunction null getValue रिस्पॉन्स को देखता है और उसे SkyValue के बजाय null लौटाना चाहिए, जिससे यह पता चलता है कि इनपुट मौजूद न होने की वजह से यह अधूरा है. पहले अनुरोध किए गए सभी SkyValues उपलब्ध होने पर, Skyframe के उपलब्ध होने पर, SkyFrame को फिर से फिर से शुरू किया जाता है.

SkyKeyComputeState के आने से पहले, रीस्टार्ट करने का पारंपरिक तरीका कंप्यूटेशन को पूरी तरह से फिर से चलाना था. हालांकि, इसमें क्वाड्रेटिक कॉम्प्लेक्सिटी है, लेकिन इस तरीके से लिखे गए फ़ंक्शन आखिर में पूरे हो जाते हैं, क्योंकि हर बार फिर से चलाए जाने पर, कम लुकअप null जनरेट करता है. SkyKeyComputeState की मदद से, हाथ से तय किए गए चेक-पॉइंट डेटा को SkyFunction के साथ जोड़ा जा सकता है. इससे, मुश्किल काम आसानी से हो जाता है.

StateMachine ऐसे ऑब्जेक्ट हैं जो SkyKeyComputeState के अंदर रहते हैं और स्काई फ़ंक्शन के रीस्टार्ट होने पर, वर्चुअल तौर पर सभी रीकंप्यूटेशन को खत्म करते हैं (यह मानते हुए कि SkyKeyComputeState कैश मेमोरी से बाहर नहीं जाता है) सस्पेंड और फिर से एक्ज़ीक्यूशन हुक को दिखाकर, उसे फिर से चालू करते हैं.

SkyKeyComputeState में स्टेटफ़ुल कंप्यूटेशन

ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के हिसाब से, सटीक डेटा वैल्यू के बजाय SkyKeyComputeState में कंप्यूटेशनल ऑब्जेक्ट को स्टोर करना सही होता है. Java में, ऑब्जेक्ट को ले जाने वाले व्यवहार का कम से कम ब्यौरा एक फ़ंक्शनल इंटरफ़ेस होता है और यह काफ़ी होता है. StateMachine में ये चीज़ें शामिल हैं, जो बार-बार बदलती रहती हैं. इसकी परिभाषा2.

@FunctionalInterface
public interface StateMachine {
  StateMachine step(Tasks tasks) throws InterruptedException;
}

Tasks का इंटरफ़ेस, SkyFunction.Environment के जैसा है. हालांकि, इसे एसिंक्रोनस के लिए डिज़ाइन किया गया है. साथ ही, यह लॉजिक के साथ एक साथ किए जाने वाले सबटास्क के लिए सहायता उपलब्ध कराता है3.

step की रिटर्न वैल्यू एक और StateMachine है. इससे चरणों के क्रम की जानकारी, इंडक्टिव तरीके से दी जाती है. step, StateMachine के पूरा हो जाने पर DONE वैल्यू दिखाता है. उदाहरण के लिए:

class HelloWorld implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    System.out.println("hello");
    return this::step2;  // The next step is HelloWorld.step2.
  }

  private StateMachine step2(Tasks tasks) {
     System.out.println("world");
     // DONE is special value defined in the `StateMachine` interface signaling
     // that the computation is done.
     return DONE;
  }
}

नीचे दिए गए आउटपुट के साथ StateMachine का ब्यौरा देता है.

hello
world

ध्यान दें कि तरीके का रेफ़रंस this::step2 भी StateMachine है, क्योंकि StateMachine के फ़ंक्शनल इंटरफ़ेस की परिभाषा step2 के हिसाब से है. तरीकों के रेफ़रंस, StateMachine में अगली स्थिति बताने का सबसे आम तरीका है.

निलंबित और फिर से शुरू करना

आसानी से कंप्यूटेशन को मोनोलिथिक फ़ंक्शन के बजाय, StateMachine चरणों में बांटा जाता है. इससे किसी कंप्यूटेशन को suspend करने और suspend करने के लिए ज़रूरी हुक मिलते हैं. जब StateMachine.step वापस लौटता है, तो साफ़ तौर पर निलंबन का एक पॉइंट दिखता है. वापस दी गई StateMachine वैल्यू के आगे बताए गए क्रम को एक साफ़ तौर पर रिज़्यूमे पॉइंट के तौर पर दिखाया गया है. इसलिए, रीकंप्यूटेशन (हिसाब लगाना) से बचा जा सकता है, क्योंकि कंप्यूटेशन को ठीक वहीं से शुरू किया जा सकता है जहां उसे छोड़ा गया था.

कॉलबैक, कंटिन्युएशन, और एसिंक्रोनस कंप्यूटेशन

तकनीकी भाषा में, StateMachine एक continuation का काम करता है, जिससे यह तय होता है कि बाद में होने वाली कंप्यूटेशन की वैल्यू को एक्ज़ीक्यूट करना है या नहीं. ब्लॉक करने के बजाय, StateMachine अपने-आप ही step फ़ंक्शन से वापस लौटकर, suspend कर सकता है. इससे कंट्रोल, वापस Driver इंस्टेंस पर ट्रांसफ़र हो जाता है. इसके बाद, Driver पहले से तैयार StateMachine पर स्विच कर सकता है या कंट्रोल को फिर से Skyframe पर छोड़ सकता है.

परंपरागत रूप से, callbacks और callbacks को एक ही सिद्धांत में रखा गया है. हालांकि, StateMachine इन दोनों के बीच अंतर बनाए रखता है.

  • कॉलबैक - इससे पता चलता है कि एसिंक्रोनस कंप्यूटेशन के नतीजे को कहां सेव करना है.
  • कंटिन्युएशन - एक्ज़ीक्यूशन की अगली स्थिति के बारे में बताता है.

एसिंक्रोनस कार्रवाई शुरू करते समय कॉलबैक ज़रूरी होते हैं. इसका मतलब है कि तरीके को कॉल करने के तुरंत बाद असल में नहीं होता है, जैसा कि SkyValue लुकअप के मामले में होता है. कॉलबैक को जितना हो सके उतना आसान रखें.

कंटिन्युएशन, StateMachine की रिटर्न वैल्यू होती हैं, जो StateMachine की रिटर्न वैल्यू होती हैं. ये सभी एसिंक्रोनस कंप्यूटेशन के हल हो जाने के बाद, कॉम्प्लेक्स एक्ज़ीक्यूशन को इनकैप्सुलेट करती हैं. इस स्ट्रक्चर्ड तरीके से, कॉलबैक की प्रोसेस को मैनेज करना आसान हो जाता है.

Tasks

Tasks इंटरफ़ेस StateMachine में एक एपीआई उपलब्ध कराता है, ताकि SkyKey के ज़रिए SkyValues का पता लगाया जा सके और एक साथ किए जाने वाले सबटास्क शेड्यूल किए जा सकें.

interface Tasks {
  void enqueue(StateMachine subtask);

  void lookUp(SkyKey key, Consumer<SkyValue> sink);

  <E extends Exception>
  void lookUp(SkyKey key, Class<E> exceptionClass, ValueOrExceptionSink<E> sink);

  // lookUp overloads for 2 and 3 exception types exist, but are elided here.
}
में पूरे हो जाते हैं.

SkyValue लुकअप

StateMachines, SkyValues देखने के लिए Tasks.lookUp ओवरलोड का इस्तेमाल करते हैं. ये SkyFunction.Environment.getValue और SkyFunction.Environment.getValueOrThrow के हिसाब से होते हैं. साथ ही, इनमें अपवाद को मैनेज करने वाले सिमैंटिक भी होते हैं. लागू करने की प्रोसेस तुरंत नहीं की जाती. हालांकि, ऐसा करने से पहले, वह ज़्यादा से ज़्यादा4 लुकअप को एक साथ बैच बना देता है. उदाहरण के लिए, ऐसा हो सकता है कि यह वैल्यू तुरंत उपलब्ध न हो. उदाहरण के लिए, ऐसा हो सकता है कि स्काईफ़्रेम रीस्टार्ट करना ज़रूरी हो. इसलिए, कॉलर यह बताता है कि कॉलबैक का इस्तेमाल करके, इस वैल्यू का क्या करना है.

StateMachine प्रोसेसर (Driver और उसे SkyFrame में जोड़कर) यह गारंटी देता है कि मान, अगली स्थिति शुरू होने से पहले उपलब्ध हो गया है. इसका एक उदाहरण यहां दिया गया है.

class DoesLookup implements StateMachine, Consumer<SkyValue> {
  private Value value;

  @Override
  public StateMachine step(Tasks tasks) {
    tasks.lookUp(new Key(), (Consumer<SkyValue>) this);
    return this::processValue;
  }

  // The `lookUp` call in `step` causes this to be called before `processValue`.
  @Override  // Implementation of Consumer<SkyValue>.
  public void accept(SkyValue value) {
    this.value = (Value)value;
  }

  private StateMachine processValue(Tasks tasks) {
    System.out.println(value);  // Prints the string representation of `value`.
    return DONE;
  }
}

ऊपर दिए गए उदाहरण में, पहले चरण में new Key() को खोजा गया है और this को उपभोक्ता के तौर पर पास किया गया है. ऐसा इसलिए हो सकता है, क्योंकि DoesLookup, Consumer<SkyValue> को लागू करता है.

समझौते के हिसाब से, अगली स्थिति DoesLookup.processValue के शुरू होने से पहले, DoesLookup.step के सभी लुकअप पूरे हो जाएंगे. इसलिए, value को तब उपलब्ध कराया जाता है, जब इसे processValue में ऐक्सेस किया जाता है.

सबटास्क

Tasks.enqueue, तर्क के साथ एक साथ किए जाने वाले सबटास्क चलाने का अनुरोध करता है. सबटास्क भी StateMachine की मदद से किए जा सकते हैं. ये वे सब भी कर सकते हैं जो StateMachine सामान्य तौर पर कर सकते हैं. इनमें बार-बार सबटास्क बनाना या SkyValues देखना शामिल है. lookUp की तरह ही, स्टेट मशीन ड्राइवर यह पक्का करता है कि अगले चरण पर जाने से पहले सभी सबटास्क पूरे हो जाएं. इसका एक उदाहरण यहां दिया गया है.

class Subtasks implements StateMachine {
  private int i = 0;

  @Override
  public StateMachine step(Tasks tasks) {
    tasks.enqueue(new Subtask1());
    tasks.enqueue(new Subtask2());
    // The next step is Subtasks.processResults. It won't be called until both
    // Subtask1 and Subtask 2 are complete.
    return this::processResults;
  }

  private StateMachine processResults(Tasks tasks) {
    System.out.println(i);  // Prints "3".
    return DONE;  // Subtasks is done.
  }

  private class Subtask1 implements StateMachine {
    @Override
    public StateMachine step(Tasks tasks) {
      i += 1;
      return DONE;  // Subtask1 is done.
    }
  }

  private class Subtask2 implements StateMachine {
    @Override
    public StateMachine step(Tasks tasks) {
      i += 2;
      return DONE;  // Subtask2 is done.
    }
  }
}

हालांकि, Subtask1 और Subtask2 एक ही समय पर एक साथ चलते हैं, लेकिन सब कुछ एक ही थ्रेड में चलता है. इसलिए, i के "एक साथ कई अपडेट" को सिंक करने की ज़रूरत नहीं होती.

स्ट्रक्चर्ड कॉनकरंसी

अगली स्थिति पर जाने से पहले, हर lookUp और enqueue का रिज़ॉल्व होना ज़रूरी है. इसका मतलब है कि एक साथ कई ऑब्जेक्ट, ट्री स्ट्रक्चर तक सीमित हैं. क्रम के हिसाब से5 एक साथ कई वैल्यू बनाई जा सकती हैं, जैसा कि इस उदाहरण में दिखाया गया है.

स्ट्रक्चर्ड कॉनकरेंसी

UML से यह कहना मुश्किल है कि एक साथ कई काम करने वाले स्ट्रक्चर से एक पेड़ बनता है. इसमें एक वैकल्पिक व्यू मौजूद है, जो पेड़ की बनावट को बेहतर ढंग से दिखाता है.

अनस्ट्रक्चर्ड कॉनकरेंसी

एक साथ कई काम करने के आंकड़ों की वजह समझना आसान है.

कंपोज़िशन और कंट्रोल फ़्लो पैटर्न

इस सेक्शन में ऐसे उदाहरण दिए गए हैं जिनसे पता चलता है कि एक से ज़्यादा StateMachine कैसे बनाए जा सकते हैं. साथ ही, कंट्रोल फ़्लो से जुड़ी कुछ समस्याओं को हल करने के तरीके भी बताए गए हैं.

क्रम के बाद वाली स्थितियां

यह सबसे सामान्य और सीधा कंट्रोल फ़्लो पैटर्न है. इसका एक उदाहरण स्टेटफ़ुल कंप्यूटेशन SkyKeyComputeState में दिखाया गया है.

ब्रांचिंग

StateMachine में ब्रांचिंग स्टेटस पाने के लिए, सामान्य Java कंट्रोल फ़्लो का इस्तेमाल करके अलग-अलग वैल्यू दिखाई जा सकती हैं. इसका उदाहरण नीचे दिया गया है.

class Branch implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    // Returns different state machines, depending on condition.
    if (shouldUseA()) {
      return this::performA;
    }
    return this::performB;
  }
  …
}

कुछ शाखाओं के लिए, जल्दी पूरा होने के लिए DONE लौटाना आम बात है.

बेहतर क्रम में कंपोज़िशन

StateMachine की कंट्रोल स्ट्रक्चर में मेमोरी नहीं होती है. इसलिए, StateMachine की डेफ़िनिशन को सबटास्क के तौर पर शेयर करना कभी-कभी खराब हो सकता है. मान लें कि M1 और M2 StateMachine, S और M1 को शेयर करते हैं. साथ ही, M1 और M2 क्रम <A, S, B> और <X, S, Y> क्रम हैं.StateMachine समस्या यह है कि S को यह पता नहीं होता कि पूरा होने के बाद B या Y पर जारी रखना है या नहीं. साथ ही, StateMachine कॉल स्टैक को ठीक से नहीं रख पाते हैं. इस सेक्शन में, इस लक्ष्य को हासिल करने की कुछ तकनीकों के बारे में बताया गया है.

टर्मिनल क्रम एलिमेंट के तौर पर StateMachine

इससे शुरुआती समस्या हल नहीं होती. यह सिर्फ़ तब सीक्वेंस कंपोज़िशन दिखाता है, जब शेयर किया गया StateMachine, सीक्वेंस में टर्मिनल होता है.

// S is the shared state machine.
class S implements StateMachine { … }

class M1 implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    performA();
    return new S();
  }
}

class M2 implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    performX();
    return new S();
  }
}

यह तब भी काम करता है, जब S खुद एक कॉम्प्लेक्स स्टेट मशीन है.

क्रम में चलने वाली कंपोज़िशन के लिए सबटास्क

इस बात की गारंटी है कि सूची में जोड़े गए सबटास्क, अगली स्थिति से पहले पूरे हो जाएंगे. इसलिए, कभी-कभी सबटास्क के तरीके का थोड़ा गलत इस्तेमाल6 किया जा सकता है.

class M1 implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    performA();
    // S starts after `step` returns and by contract must complete before `doB`
    // begins. It is effectively sequential, inducing the sequence < A, S, B >.
    tasks.enqueue(new S());
    return this::doB;
  }

  private StateMachine doB(Tasks tasks) {
    performB();
    return DONE;
  }
}

class M2 implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    performX();
    // Similarly, this induces the sequence < X, S, Y>.
    tasks.enqueue(new S());
    return this::doY;
  }

  private StateMachine doY(Tasks tasks) {
    performY();
    return DONE;
  }
}

runAfter इंजेक्शन

कभी-कभी, Tasks.enqueue का गलत इस्तेमाल करना मुमकिन नहीं होता, क्योंकि ऐसे अन्य सबटास्क या Tasks.lookUp कॉल भी होते हैं जिन्हें S के लागू होने से पहले पूरा करना ज़रूरी होता है. इस मामले में, runAfter पैरामीटर को S में इंजेक्ट करके, S को यह जानकारी दी जा सकती है कि आगे क्या करना है.

class S implements StateMachine {
  // Specifies what to run after S completes.
  private final StateMachine runAfter;

  @Override
  public StateMachine step(Tasks tasks) {
    … // Performs some computations.
    return this::processResults;
  }

  @Nullable
  private StateMachine processResults(Tasks tasks) {
    … // Does some additional processing.

    // Executes the state machine defined by `runAfter` after S completes.
    return runAfter;
  }
}

class M1 implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    performA();
    // Passes `this::doB` as the `runAfter` parameter of S, resulting in the
    // sequence < A, S, B >.
    return new S(/* runAfter= */ this::doB);
  }

  private StateMachine doB(Tasks tasks) {
    performB();
    return DONE;
  }
}

class M2 implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks) {
    performX();
    // Passes `this::doY` as the `runAfter` parameter of S, resulting in the
    // sequence < X, S, Y >.
    return new S(/* runAfter= */ this::doY);
  }

  private StateMachine doY(Tasks tasks) {
    performY();
    return DONE;
  }
}

यह तरीका, सबटास्क का गलत इस्तेमाल करने से बेहतर है. हालांकि, इसे बहुत सोच-समझकर लागू करना. उदाहरण के लिए, runAfter के साथ कई StateMachine को नेस्ट करना, कॉलबैक हेल का रास्ता है. सिक्वेंशल runAfter को सामान्य क्रम में चलने वाले स्थितियों में बांटना बेहतर होता है.

  return new S(/* runAfter= */ new T(/* runAfter= */ this::nextStep))

को निम्न से बदला जा सकता है.

  private StateMachine step1(Tasks tasks) {
     doStep1();
     return new S(/* runAfter= */ this::intermediateStep);
  }

  private StateMachine intermediateStep(Tasks tasks) {
    return new T(/* runAfter= */ this::nextStep);
  }

अनुमति नहीं है विकल्प: runAfterUnlessError

इससे पहले के ड्राफ़्ट में, हमने runAfterUnlessError को लागू करने के बारे में सोचा था, जो गड़बड़ियों को जल्द ही खत्म कर देगा. यह इस तथ्य के कारण प्रेरित हुआ कि गड़बड़ियों की अक्सर दो बार जांच की जाती है, एक बार StateMachine से, जिसमें runAfter संदर्भ होता है और एक बार runAfter मशीन से.

कुछ सोच-विचार करने के बाद, हमने तय किया कि गड़बड़ी की जांच करने की कॉपी की तुलना में कोड की एकरूपता ज़्यादा ज़रूरी है. अगर runAfter तरीका, tasks.enqueue तकनीक के मुताबिक काम नहीं करता है, तो यह भ्रम की स्थिति पैदा करेगा. इसमें हमेशा गड़बड़ी की जांच करना ज़रूरी होता है.

सीधे तौर पर ऐक्सेस देना

हर बार फ़ॉर्मल स्टेट ट्रांज़िशन होने पर, मुख्य Driver लूप आगे बढ़ जाता है. समझौते के मुताबिक, स्थितियों को बेहतर बनाने का मतलब है कि पहले लाइन में जोड़े गए सभी SkyValue लुकअप और सबटास्क, अगली स्थिति के चालू होने से पहले ठीक हो जाते हैं. कभी-कभी StateMachine डेलिगेट के लॉजिक के हिसाब से, फ़ेज़ को ऐडवांस बनाना ज़रूरी नहीं है या इससे मुश्किल हो सकती है. उदाहरण के लिए, अगर डेलिगेट का पहला step SkyKey लुकअप करता है, जिसे डेलिगेट करने की स्थिति के लुकअप के साथ साथ चलाया जा सकता है, तो आगे बढ़ने पर चरण क्रम में आ जाएंगे. जैसा कि नीचे दिए गए उदाहरण में दिखाया गया है, सीधे ऐक्सेस देने की बेहतर सुविधा हो सकती है.

class Parent implements StateMachine {
  @Override
  public StateMachine step(Tasks tasks ) {
    tasks.lookUp(new Key1(), this);
    // Directly delegates to `Delegate`.
    //
    // The (valid) alternative:
    //   return new Delegate(this::afterDelegation);
    // would cause `Delegate.step` to execute after `step` completes which would
    // cause lookups of `Key1` and `Key2` to be sequential instead of parallel.
    return new Delegate(this::afterDelegation).step(tasks);
  }

  private StateMachine afterDelegation(Tasks tasks) {
    …
  }
}

class Delegate implements StateMachine {
  private final StateMachine runAfter;

  Delegate(StateMachine runAfter) {
    this.runAfter = runAfter;
  }

  @Override
  public StateMachine step(Tasks tasks) {
    tasks.lookUp(new Key2(), this);
    return …;
  }

  // Rest of implementation.
  …

  private StateMachine complete(Tasks tasks) {
    …
    return runAfter;
  }
}

डेटा फ़्लो

पिछली बातचीत का मुख्य मकसद, कंट्रोल फ़्लो को मैनेज करना था. इस सेक्शन में, डेटा की वैल्यू को प्रोपगेशन के बारे में बताया गया है.

Tasks.lookUp कॉलबैक लागू किया जा रहा है

SkyValue लुकअप में, Tasks.lookUp कॉलबैक लागू करने का एक उदाहरण दिया गया है. इस सेक्शन में, एक से ज़्यादा SkyValues को हैंडल करने की वजह और सुझाव दिए गए हैं.

Tasks.lookUp कॉलबैक

Tasks.lookUp वाला तरीका, पैरामीटर के तौर पर कॉलबैक, sink को लेता है.

  void lookUp(SkyKey key, Consumer<SkyValue> sink);

इसे लागू करने के लिए, मुहावरे वाला तरीका Java लैम्डा का इस्तेमाल करना होगा:

  tasks.lookUp(key, value -> myValue = (MyValueClass)value);

जहां myValue, लुकअप कर रहे StateMachine इंस्टेंस का सदस्य वैरिएबल है. हालांकि, StateMachine लागू करने में Consumer<SkyValue> इंटरफ़ेस को लागू करने की तुलना में, Lambda फ़ंक्शन को ज़्यादा मेमोरी की ज़रूरत होती है. Lambda फ़ंक्शन तब भी मददगार होता है, जब एक से ज़्यादा लुकअप हों और उन्हें समझना मुश्किल हो.

Tasks.lookUp के ओवरलोड को मैनेज करने में भी गड़बड़ियां पाई गई हैं. ये गड़बड़ियां SkyFunction.Environment.getValueOrThrow के जैसे हैं.

  <E extends Exception> void lookUp(
      SkyKey key, Class<E> exceptionClass, ValueOrExceptionSink<E> sink);

  interface ValueOrExceptionSink<E extends Exception> {
    void acceptValueOrException(@Nullable SkyValue value, @Nullable E exception);
  }

इसे लागू करने का एक उदाहरण नीचे दिया गया है.

class PerformLookupWithError extends StateMachine, ValueOrExceptionSink<MyException> {
  private MyValue value;
  private MyException error;

  @Override
  public StateMachine step(Tasks tasks) {
    tasks.lookUp(new MyKey(), MyException.class, ValueOrExceptionSink<MyException>) this);
    return this::processResult;
  }

  @Override
  public acceptValueOrException(@Nullable SkyValue value, @Nullable MyException exception) {
    if (value != null) {
      this.value = (MyValue)value;
      return;
    }
    if (exception != null) {
      this.error = exception;
      return;
    }
    throw new IllegalArgumentException("Both parameters were unexpectedly null.");
  }

  private StateMachine processResult(Tasks tasks) {
    if (exception != null) {
      // Handles the error.
      …
      return DONE;
    }
    // Processes `value`, which is non-null.
    …
  }
}

अगर बिना किसी गड़बड़ी के हैंडलिंग वाले लुकअप के साथ काम किया जाता है, तो कॉलबैक को सीधे तौर पर लागू करने पर StateMachine क्लास, लांबा के लिए मेमोरी ऐलोकेशन को बचाती है.

गड़बड़ी मैनेज करना थोड़ी और जानकारी देता है, लेकिन गड़बड़ियों और सामान्य वैल्यू के प्रोपगेशन में ज़्यादा अंतर नहीं है.

एक से ज़्यादा SkyValues का इस्तेमाल करना

अक्सर, एक से ज़्यादा SkyValue लुकअप की ज़रूरत होती है. SkyValue के टाइप पर स्विच करना, ज़्यादातर समय काम करने वाला एक तरीका है. यहां एक उदाहरण दिया गया है, जिसे प्रोटोटाइप प्रोडक्शन कोड की मदद से आसान बनाया गया है.

  @Nullable
  private StateMachine fetchConfigurationAndPackage(Tasks tasks) {
    var configurationKey = configuredTarget.getConfigurationKey();
    if (configurationKey != null) {
      tasks.lookUp(configurationKey, (Consumer<SkyValue>) this);
    }

    var packageId = configuredTarget.getLabel().getPackageIdentifier();
    tasks.lookUp(PackageValue.key(packageId), (Consumer<SkyValue>) this);

    return this::constructResult;
  }

  @Override  // Implementation of `Consumer<SkyValue>`.
  public void accept(SkyValue value) {
    if (value instanceof BuildConfigurationValue) {
      this.configurationValue = (BuildConfigurationValue) value;
      return;
    }
    if (value instanceof PackageValue) {
      this.pkg = ((PackageValue) value).getPackage();
      return;
    }
    throw new IllegalArgumentException("unexpected value: " + value);
  }

Consumer<SkyValue> कॉलबैक को लागू करने की प्रोसेस को साफ़ तौर पर शेयर किया जा सकता है, क्योंकि वैल्यू टाइप अलग-अलग होते हैं. अगर ऐसा नहीं है, तो सही कॉलबैक लागू करने वाले Lambda-आधारित इंप्लिमेंटेशन या फ़ुल इनर-क्लास इंस्टेंस पर वापस आना बेहतर होता है.

StateMachine के बीच वैल्यू ट्रांसफ़र की जा रही हैं

अब तक, इस दस्तावेज़ में सिर्फ़ सबटास्क में काम को व्यवस्थित करने का तरीका बताया गया है. हालांकि, सबटास्क के लिए भी कॉलर को वैल्यू की जानकारी भेजनी होगी. सबटास्क लॉजिकल रूप से एसिंक्रोनस होते हैं. इसलिए, कॉलर को कॉलबैक का इस्तेमाल करके उनके नतीजों की जानकारी दी जाती है. यह काम करने के लिए, सबटास्क एक सिंक इंटरफ़ेस को परिभाषित करता है, जिसे इसके कंस्ट्रक्टर के ज़रिए इंजेक्ट किया जाता है.

class BarProducer implements StateMachine {
  // Callers of BarProducer implement the following interface to accept its
  // results. Exactly one of the two methods will be called by the time
  // BarProducer completes.
  interface ResultSink {
    void acceptBarValue(Bar value);
    void acceptBarError(BarException exception);
  }

  private final ResultSink sink;

  BarProducer(ResultSink sink) {
     this.sink = sink;
  }

  … // StateMachine steps that end with this::complete.

  private StateMachine complete(Tasks tasks) {
    if (hasError()) {
      sink.acceptBarError(getError());
      return DONE;
    }
    sink.acceptBarValue(getValue());
    return DONE;
  }
}

इसके बाद, कॉलर StateMachine कुछ ऐसा दिखेगा.

class Caller implements StateMachine, BarProducer.ResultSink {
  interface ResultSink {
    void acceptCallerValue(Bar value);
    void acceptCallerError(BarException error);
  }

  private final ResultSink sink;

  private Bar value;

  Caller(ResultSink sink) {
    this.sink = sink;
  }

  @Override
  @Nullable
  public StateMachine step(Tasks tasks) {
    tasks.enqueue(new BarProducer((BarProducer.ResultSink) this));
    return this::processResult;
  }

  @Override
  public void acceptBarValue(Bar value) {
    this.value = value;
  }

  @Override
  public void acceptBarError(BarException error) {
    sink.acceptCallerError(error);
  }

  private StateMachine processResult(Tasks tasks) {
    // Since all enqueued subtasks resolve before `processResult` starts, one of
    // the `BarResultSink` callbacks must have been called by this point.
    if (value == null) {
      return DONE;  // There was a previously reported error.
    }
    var finalResult = computeResult(value);
    sink.acceptCallerValue(finalResult);
    return DONE;
  }
}

पिछले उदाहरण में इससे जुड़ी कुछ चीज़ें बताई गई हैं. Caller को अपने नतीजे वापस लागू करने होंगे और खुद का Caller.ResultSink तय करना होगा. Caller, BarProducer.ResultSink कॉलबैक लागू करता है. फिर से शुरू करने पर, processResult यह पता लगाता है कि कोई गड़बड़ी हुई है या नहीं. यह पता लगाने के लिए कि value की वैल्यू शून्य है या नहीं. यह किसी सबटास्क या SkyValue लुकअप से आउटपुट स्वीकार करने के बाद होने वाला सामान्य व्यवहार पैटर्न है.

ध्यान दें कि acceptBarError को लागू करने से नतीजे, जल्द से जल्द Caller.ResultSink पर भेज दिए जाते हैं. ऐसा गड़बड़ी के बबल की प्रोसेस के मुताबिक करना ज़रूरी होता है.

टॉप लेवल StateMachine के विकल्पों के बारे में Drivers और SkyFunctions में जोड़ने के बारे में बताया गया है.

गड़बड़ी ठीक करना

Tasks.lookUp कॉलबैक और StateMachines के बीच वैल्यू को ट्रांसफ़र करने में, पहले से ही गड़बड़ियों को मैनेज करने के कुछ उदाहरण दिए गए हैं. InterruptedException के अलावा, दूसरे अपवादों को नहीं निकाला जाता, बल्कि इसके बजाय उन्हें कॉलबैक से वैल्यू के रूप में पास किया जाता है. ऐसे कॉलबैक में अक्सर खास या सिमैंटिक होते हैं. इनमें से कोई एक वैल्यू या गड़बड़ी पास होती है.

अगले सेक्शन में, Skyframe की गड़बड़ियों को मैनेज करने के बारे में आसान, लेकिन अहम इंटरैक्शन के बारे में बताया गया है.

बबल करने में गड़बड़ी (--nokeep_going)

गड़बड़ी के बबल होने के दौरान, SkyFunction को रीस्टार्ट हो सकता है. भले ही, अनुरोध किए गए सभी SkyValues उपलब्ध न हों. ऐसे मामलों में, Tasks API अनुबंध की वजह से बाद वाले राज्य से कभी नहीं संपर्क किया जा सकता. हालांकि, StateMachine को अब भी अपवाद को लागू करना चाहिए.

अगला स्टेटस आने या न होने की परवाह किए बिना, प्रोपेगेशन होना ज़रूरी है. इसलिए, गड़बड़ी को हैंडल करने वाले कॉलबैक से यह टास्क ज़रूर होना चाहिए. इनर StateMachine के लिए, पैरंट कॉलबैक को शुरू करके ऐसा किया जाता है.

सबसे ऊपर के StateMachine लेवल पर, जो SkyFunction के साथ इंटरफ़ेस करता है. इस प्रोसेस को ValueOrExceptionProducer के setException तरीके को कॉल करके किया जा सकता है. इसके बाद, ValueOrExceptionProducer.tryProduceValue अपवाद को दिखाएगा, भले ही SkyValues मौजूद न हों.

अगर Driver का सीधे तौर पर इस्तेमाल किया जा रहा है, तो SkyFunction से होने वाली गड़बड़ियों की जांच करना ज़रूरी है. भले ही, मशीन ने प्रोसेसिंग को पूरा न किया हो.

इवेंट हैंडलिंग

जिन SkyFunctions को इवेंट उत्सर्जन करने की ज़रूरत होती है उनके लिए, StoredEventHandler को SkyKeyComputeState में इंजेक्ट किया जाता है. इसके बाद, उन्हें उन StateMachine में इंजेक्ट किया जाता है जिनके लिए उन्हें इनकी ज़रूरत होती है. पहले, StoredEventHandler की ज़रूरत तब तक पड़ती थी, जब तक SkyFrame के कुछ इवेंट बंद होते थे, जब तक कि उन्हें फिर से नहीं चलाया जाता, लेकिन बाद में यह समस्या ठीक कर दी गई. StoredEventHandler इंजेक्शन को सुरक्षित रखा गया है, क्योंकि यह गड़बड़ी को हैंडल करने वाले कॉलबैक से जनरेट होने वाले इवेंट को लागू करने की प्रोसेस को आसान बनाता है.

Drivers और SkyFunctions पर जोड़ना

तय किए गए रूट StateMachine से शुरू होने वाले StateMachine को लागू करने की ज़िम्मेदारी Driver की होती है. StateMachines बार-बार सबटास्क StateMachineकी सूची में जोड़ सकते हैं. इसलिए, एक Driver में कई सबटास्क मैनेज किए जा सकते हैं. ये सबटास्क, स्ट्रक्चर्ड एक साथ कई काम करने की प्रोसेस की वजह से ट्री स्ट्रक्चर बनाते हैं. Driver, बेहतर दक्षता के लिए सबटास्क में SkyValue को बैच करता है.

Driver की मदद से, नीचे दिए गए एपीआई के साथ कई क्लास बनाई गई हैं.

public final class Driver {
  public Driver(StateMachine root);
  public boolean drive(SkyFunction.Environment env) throws InterruptedException;
}

Driver, पैरामीटर के तौर पर सिंगल रूट StateMachine को लेता है. Driver.drive को कॉल करने पर, StateMachine उतनी दूर तक एक्ज़ीक्यूट होता है जितना कि वह स्काईफ़्रेम रीस्टार्ट किए बिना चल सकता है. StateMachine के पूरा होने पर यह 'सही' दिखाता है. वहीं, 'गलत' दिखाता है. इससे पता चलता है कि सभी वैल्यू उपलब्ध नहीं हैं.

Driver, StateMachine की एक ही समय पर स्थिति को बनाए रखता है और यह SkyKeyComputeState में एम्बेड करने के लिए बेहतर है.

Driver को सीधे तौर पर इंस्टैंशिएट किया जा रहा है

StateMachine लागू करने पर, पारंपरिक तरीके से कॉलबैक के ज़रिए नतीजे दिए जाते हैं. नीचे दिए गए उदाहरण में दिखाए गए तरीके से, Driver को सीधे तौर पर इंस्टैंशिएट किया जा सकता है.

Driver को SkyKeyComputeState लागू करने के तरीके में एम्बेड किया गया है. साथ ही, इससे जुड़ी ResultSink को लागू किया गया है, ताकि इसकी जानकारी नीचे दी जा सके. सबसे ऊपर के लेवल पर, कंप्यूटेशन के नतीजे के लिए State ऑब्जेक्ट सही रिसीवर के तौर पर काम करता है, क्योंकि इसके Driver से बाहर निकल जाने की गारंटी होती है.

class State implements SkyKeyComputeState, ResultProducer.ResultSink {
  // The `Driver` instance, containing the full tree of all `StateMachine`
  // states. Responsible for calling `StateMachine.step` implementations when
  // asynchronous values are available and performing batched SkyFrame lookups.
  //
  // Non-null while `result` is being computed.
  private Driver resultProducer;

  // Variable for storing the result of the `StateMachine`
  //
  // Will be non-null after the computation completes.
  //
  private ResultType result;

  // Implements `ResultProducer.ResultSink`.
  //
  // `ResultProducer` propagates its final value through a callback that is
  // implemented here.
  @Override
  public void acceptResult(ResultType result) {
    this.result = result;
  }
}

नीचे दिया गया कोड, ResultProducer को स्केच करता है.

class ResultProducer implements StateMachine {
  interface ResultSink {
    void acceptResult(ResultType value);
  }

  private final Parameters parameters;
  private final ResultSink sink;

  … // Other internal state.

  ResultProducer(Parameters parameters, ResultSink sink) {
    this.parameters = parameters;
    this.sink = sink;
  }

  @Override
  public StateMachine step(Tasks tasks) {
    …  // Implementation.
    return this::complete;
  }

  private StateMachine complete(Tasks tasks) {
    sink.acceptResult(getResult());
    return DONE;
  }
}

फिर, लेज़ी तरीके से नतीजे का पता लगाने के लिए इस्तेमाल किया गया कोड कुछ ऐसा दिख सकता है.

@Nullable
private Result computeResult(State state, Skyfunction.Environment env)
    throws InterruptedException {
  if (state.result != null) {
    return state.result;
  }
  if (state.resultProducer == null) {
    state.resultProducer = new Driver(new ResultProducer(
      new Parameters(), (ResultProducer.ResultSink)state));
  }
  if (state.resultProducer.drive(env)) {
    // Clears the `Driver` instance as it is no longer needed.
    state.resultProducer = null;
  }
  return state.result;
}

Driver को एम्बेड किया जा रहा है

अगर StateMachine से कोई वैल्यू जनरेट होती है और उसमें कोई अपवाद नहीं जोड़ा जाता, तो एम्बेड Driver को लागू किया जा सकता है. इसे इस उदाहरण में दिखाया गया है.

class ResultProducer implements StateMachine {
  private final Parameters parameters;
  private final Driver driver;

  private ResultType result;

  ResultProducer(Parameters parameters) {
    this.parameters = parameters;
    this.driver = new Driver(this);
  }

  @Nullable  // Null when a Skyframe restart is needed.
  public ResultType tryProduceValue( SkyFunction.Environment env)
      throws InterruptedException {
    if (!driver.drive(env)) {
      return null;
    }
    return result;
  }

  @Override
  public StateMachine step(Tasks tasks) {
    …  // Implementation.
}

SkyFunction में ऐसा कोड हो सकता है जो ऐसा दिखता है (जहां State फ़ंक्शन खास तरह का SkyKeyComputeState है).

@Nullable  // Null when a Skyframe restart is needed.
Result computeResult(SkyFunction.Environment env, State state)
    throws InterruptedException {
  if (state.result != null) {
    return state.result;
  }
  if (state.resultProducer == null) {
    state.resultProducer = new ResultProducer(new Parameters());
  }
  var result = state.resultProducer.tryProduceValue(env);
  if (result == null) {
    return null;
  }
  state.resultProducer = null;
  return state.result = result;
}

StateMachine को लागू करने के तरीके में Driver को एम्बेड करना, स्काईफ़्रेम की सिंक्रोनस कोडिंग स्टाइल के लिए बेहतर है.

अपवाद पैदा करने वाली Stateमशीन

इसके अलावा, SkyKeyComputeState में एम्बेड किए जा सकने वाले ValueOrExceptionProducer और ValueOrException2Producer क्लास हैं, जिनमें सिंक्रोनस स्काई फ़ंक्शन कोड से मिलान करने के लिए सिंक्रोनस एपीआई हैं.

ValueOrExceptionProducer ऐब्सट्रैक्ट क्लास में ये तरीके शामिल हैं.

public abstract class ValueOrExceptionProducer<V, E extends Exception>
    implements StateMachine {
  @Nullable
  public final V tryProduceValue(Environment env)
      throws InterruptedException, E {
    …  // Implementation.
  }

  protected final void setValue(V value)  {  … // Implementation. }
  protected final void setException(E exception) {  … // Implementation. }
}

इसमें एम्बेड किया गया Driver इंस्टेंस शामिल है और यह एम्बेडिंग ड्राइवर में दी गई ResultProducer क्लास और उसी तरह के SkyFunction के साथ इंटरफ़ेस से मिलता-जुलता है. ResultSink तय करने के बजाय, इनमें से कोई भी काम होने पर setValue या setException को लागू करें. दोनों के होने पर, अपवाद को प्राथमिकता दी जाती है. tryProduceValue तरीका, एसिंक्रोनस कॉलबैक कोड को सिंक्रोनस कोड में जोड़ता है और सेट किए जाने पर एक अपवाद दिखाता है.

जैसा कि हमने पहले बताया था, गड़बड़ी के बबल होने के दौरान गड़बड़ी हो सकती है. भले ही, मशीन अभी तक न हुई हो, क्योंकि सभी इनपुट उपलब्ध नहीं हैं. इसे रखने के लिए, tryProduceValue सभी अपवाद के लिए अनुमति देता है, भले ही मशीन चालू हो.

उपदेश: आखिर में कॉलबैक हटाए जा रहे हैं

StateMachine एसिंक्रोनस कंप्यूटेशन (हिसाब लगाना) करने का सबसे बेहतर, लेकिन बॉयलरप्लेट का इस्तेमाल करके कंप्यूटेशन का तरीका है. Bazel कोड के कुछ हिस्सों में कॉन्टिन्यूएशन (खास तौर पर, ListenableFuture को पास किए गए Runnable) बड़े पैमाने पर होते हैं, हालांकि, विश्लेषण में इस्तेमाल किए जाने वाले SkyFunctions मौजूद नहीं हैं. विश्लेषण का ज़्यादातर हिस्सा सीपीयू (CPU) से जुड़ा होता है और डिस्क I/O के लिए कोई कारगर एसिंक्रोनस एपीआई नहीं है. आखिर में, दूसरे कॉलबैक को ऑप्टिमाइज़ करना बेहतर होगा, क्योंकि उनमें लर्निंग कर्व होता है और उन्हें पढ़ना मुश्किल होता है.

Java वर्चुअल थ्रेड, इसका सबसे अच्छा विकल्प है. कॉलबैक लिखने के बजाय, सब कुछ सिंक्रोनस और ब्लॉक करने वाले कॉल से बदल दिया जाता है. ऐसा इसलिए मुमकिन हो पाता है, क्योंकि प्लैटफ़ॉर्म थ्रेड के उलट, वर्चुअल थ्रेड रिसॉर्स को जोड़ना सस्ता होता है. हालांकि, वर्चुअल थ्रेड के साथ भी, आसान सिंक्रोनस ऑपरेशन की जगह थ्रेड बनाने और सिंक करने के बुनियादी नियम बहुत महंगे होते हैं. हमने StateMachine से Java वर्चुअल थ्रेड पर माइग्रेट किया. ये थ्रेड लोड होने में ज़्यादा समय लेने लगे थे. इस वजह से, शुरू से आखिर तक विश्लेषण में लगने वाले समय में करीब तीन गुना बढ़ोतरी हुई. वर्चुअल थ्रेड अब भी झलक देखने की सुविधा के तौर पर काम करती हैं. इसलिए, हो सकता है कि परफ़ॉर्मेंस बेहतर होने पर, यह माइग्रेशन बाद में भी किया जा सके.

एक और तरीका है लूम कोरूटीन के उपलब्ध होने का इंतज़ार करना. यहां लाभ यह है कि कोऑपरेटिव मल्टीटास्किंग का इस्तेमाल करके सिंक्रोनाइज़ेशन ओवरहेड को कम किया जा सकता है.

अगर बाकी सब कुछ विफल हो जाता है, तो निम्न-स्तरीय बाइटकोड को फिर से लिखना भी एक अच्छा विकल्प हो सकता है. ज़रूरत के मुताबिक ऑप्टिमाइज़ेशन होने पर, हाथ से लिखे गए कॉलबैक कोड के लिए काम करने वाली परफ़ॉर्मेंस हासिल की जा सकती है.

अन्य जानकारी

कॉलबैक नरक

कॉलबैक हेल, कॉलबैक का इस्तेमाल करने वाले एसिंक्रोनस कोड में होने वाली एक गंभीर समस्या है. इसका मतलब यह है कि अगले चरण को अगले चरण में ले जाना, पिछले चरण में ही नेस्ट किया गया है. अगर कई चरण हैं, तो यह नेस्ट करना बहुत गहरी हो सकता है. अगर कंट्रोल फ़्लो के साथ कोड का इस्तेमाल किया जाता है, तो कोड मैनेज नहीं किया जा सकेगा.

class CallbackHell implements StateMachine {
  @Override
  public StateMachine step(Tasks task) {
    doA();
    return (t, l) -> {
      doB();
      return (t1, l2) -> {
        doC();
        return DONE;
      };
    };
  }
}

नेस्ट किए गए तरीकों को लागू करने का एक फ़ायदा यह है कि बाहरी चरण के स्टैक फ़्रेम को सुरक्षित रखा जा सकता है. Java में, कैप्चर किए गए लैम्डा वैरिएबल अच्छी तरह से फ़ाइनल होने चाहिए, ताकि इस तरह के वैरिएबल का इस्तेमाल करना मुश्किल हो. डीप नेस्टिंग से बचने के लिए, लेंबडा के बजाय कंटिन्यूएशन के रेफ़रंस का इस्तेमाल करने से बचा जाता है, जैसा कि इस तरीके से दिखाया गया है.

class CallbackHellAvoided implements StateMachine {
  @Override
  public StateMachine step(Tasks task) {
    doA();
    return this::step2;
  }

  private StateMachine step2(Tasks tasks) {
    doB();
    return this::step3;
  }

  private StateMachine step3(Tasks tasks) {
    doC();
    return DONE;
  }
}

runAfter इंजेक्शन पैटर्न का बहुत ज़्यादा इस्तेमाल करने पर भी कॉलबैक से बचा जा सकता है. हालांकि, एक सिलसिलेवार तरीके से इंजेक्शन के ज़रिए दिए गए इंजेक्शन से इसे रोका जा सकता है.

उदाहरण: चेन किए गए SkyValue लुकअप

आम तौर पर, ऐप्लिकेशन लॉजिक के लिए SkyValue लुकअप की डिपेंडेंट चेन की ज़रूरत होती है. उदाहरण के लिए, अगर कोई दूसरा SkyKey पहले SkyValue पर निर्भर करता है. इस छोटे से सोचने पर इसका नतीजा यह होता है कि हमें एक कॉम्प्लेक्स और एक मज़बूत कॉलबैक किया जाना चाहिए.

private ValueType1 value1;
private ValueType2 value2;

private StateMachine step1(...) {
  tasks.lookUp(key1, (Consumer<SkyValue>) this);  // key1 has type KeyType1.
  return this::step2;
}

@Override
public void accept(SkyValue value) {
  this.value1 = (ValueType1) value;
}

private StateMachine step2(...) {
  KeyType2 key2 = computeKey(value1);
  tasks.lookup(key2, this::acceptValueType2);
  return this::step3;
}

private void acceptValueType2(SkyValue value) {
  this.value2 = (ValueType2) value;
}

हालांकि, क्रम को मेथड के रेफ़रंस के तौर पर बताया गया है, इसलिए कोड हर स्थिति में होने वाले ट्रांज़िशन के तौर पर काम करता है: step2, step1 के बाद आता है. ध्यान दें कि यहां, value2 को असाइन करने के लिए Lambda का इस्तेमाल किया जाता है. इससे कोड का क्रम ऊपर से नीचे तक की गणना के क्रम से मेल खा जाता है.

अन्य सलाह

पठनीयता: निष्पादन आदेश

कोड को आसानी से पढ़ने के लिए, कोशिश करें कि StateMachine.step लागू करने के तरीके को एक्ज़ीक्यूशन ऑर्डर और कॉलबैक इंप्लीमेंटेशन के ठीक बाद उस जगह पर रखें जहां उन्हें कोड में पास किया गया हो. जहां कंट्रोल फ़्लो की शाखाएं होती हैं वहां हमेशा ऐसा करना मुमकिन नहीं होता. ऐसे मामलों में अतिरिक्त टिप्पणियां मददगार हो सकती हैं.

उदाहरण: चेन किए गए SkyValue लुकअप में, इसे पाने के लिए बीच के लेवल का तरीका रेफ़रंस बनाया गया है. इससे रीडबिलिटी के लिए परफ़ॉर्मेंस पर काफ़ी असर पड़ता है, जो शायद यहां काम का हो.

जेनरेशनल हाइपोथीसिस

थोड़े समय तक रहने वाले Java ऑब्जेक्ट, Java गार्बेज कलेक्टर की पीढ़ी के अनुमान को तोड़ता है. इसे इस तरह से डिज़ाइन किया गया है कि यह कुछ समय के लिए रहने वाली या हमेशा रहने वाली चीज़ों के हिसाब से काम करे. परिभाषा के हिसाब से, SkyKeyComputeState में मौजूद ऑब्जेक्ट इस अनुमान का उल्लंघन करते हैं. Driver पर रूट किए गए ऐसे सभी ऑब्जेक्ट जिनमें अब भी चल रहे सभी StateMachine के कंस्ट्रक्शन का ट्री होता है, वे एसिंक्रोनस कंप्यूटेशन के पूरा होने का इंतज़ार करते हैं. साथ ही, इनके निलंबित होने की अवधि, बीच में खत्म हो जाती है.

JDK19 में यह कम खराब लगता है, लेकिन StateMachine का इस्तेमाल करते समय, कभी-कभी जीसी टाइम में बढ़ोतरी दिख सकती है. भले ही, जनरेट किए गए कचरे में नाटकीय रूप से कमी आई हो. StateMachine लंबे समय तक चलते हैं. इसलिए, उन्हें पुरानी जेनरेशन के तौर पर प्रमोट किया जा सकता है. इससे वे ज़्यादा तेज़ी से भर जाते हैं. ऐसे में, उन्हें साफ़ करने के लिए ज़्यादा महंगे बड़े या पूरे जीसी की ज़रूरत पड़ती है.

शुरुआती सावधानी यह है कि StateMachine वैरिएबल का इस्तेमाल कम किया जाए. हालांकि, हमेशा ऐसा करना मुमकिन नहीं होता. उदाहरण के लिए, ऐसा तब हो सकता है, जब एक से ज़्यादा राज्यों में वैल्यू की ज़रूरत हो. जहां मुमकिन हो वहां लोकल स्टैक step वैरिएबल, युवा जनरेशन वाले वैरिएबल होते हैं और बेहतर तरीके से जीसी किए जाते हैं.

StateMachine वैरिएबल के लिए, चीज़ों को सबटास्क में बांटना और StateMachine वैरिएबल के बीच वैल्यू को लागू करने के लिए सुझाए गए पैटर्न का पालन करना भी मददगार होता है. ध्यान दें कि पैटर्न को फ़ॉलो करते समय, सिर्फ़ चाइल्ड StateMachines के रेफ़रंस में, StateMachines के रेफ़रंस दिए जाते हैं, न कि पैरंट का रेफ़रंस. इसका मतलब यह है कि जब बच्चे नतीजे के कॉलबैक का इस्तेमाल करके, नतीजे देते हैं और माता-पिता के डेटा को अपडेट करते हैं, तो बच्चे स्वाभाविक रूप से दायरे से बाहर हो जाते हैं और उन्हें जीसी (GC) का ऐक्सेस मिल जाता है.

कुछ मामलों में, StateMachine वैरिएबल की ज़रूरत शुरुआती स्थितियों में होती है, लेकिन बाद के मामलों में नहीं. जब यह पता चलता है कि बड़े ऑब्जेक्ट की अब ज़रूरत नहीं है, तो उनके रेफ़रंस को हटाना फ़ायदेमंद हो सकता है.

नाम की स्थितियां

किसी तरीके का नाम रखते समय, आम तौर पर उस तरीके में होने वाले व्यवहार के लिए, तरीके का नाम रखा जा सकता है. StateMachine में ऐसा करने का तरीका साफ़ तौर पर नहीं बताया गया है, क्योंकि कोई स्टैक मौजूद नहीं है. उदाहरण के लिए, मान लें कि विधि foo किसी उप-मेथ bar को कॉल करती है. StateMachine में, इसे स्थिति क्रम foo में बदला जा सकता है, इसके बाद bar. foo में अब यह व्यवहार bar शामिल नहीं है. इस वजह से, राज्यों के लिए तरीकों के नाम सीमित हो जाते हैं. इससे स्थानीय व्यवहार का पता चलता है.

कॉन करंसी ट्री का डायग्राम

नीचे दिए गए डायग्राम में, स्ट्रक्चर्ड कॉनमुद्रा का एक वैकल्पिक व्यू दिखाया गया है. यह ट्री स्ट्रक्चर को बेहतर तरीके से दिखाता है. इन ब्लॉक से एक छोटा पेड़ बनता है.

स्ट्रक्चर्ड कॉनकरेंसी 3D

  1. वैल्यू उपलब्ध न होने पर, Skyframe में शुरुआत से ही रीस्टार्ट करने का तरीका उलटा है.↩

  2. ध्यान दें कि step को InterruptedException फेंकने की अनुमति है, लेकिन उदाहरण में इसे छोड़ दिया गया है. Bazel कोड में कुछ कम तरीके होते हैं जो इस अपवाद के बारे में बताते हैं और Driver तक अपने-आप लागू हो जाते हैं. इसके बारे में बाद में बताया जाएगा, जो StateMachine को चलाता है. ज़रूरत न होने पर, इसे फेंकने के लिए एलान न किया जा सकता है.↩

  3. एक साथ चलाए जा सकने वाले सबटास्क, ConfiguredTargetFunction ने किए. ये हर डिपेंडेंसी के लिए स्वतंत्र काम करते हैं. सभी डिपेंडेंसी को एक साथ प्रोसेस करने वाले मुश्किल डेटा स्ट्रक्चर में हेर-फेर करने के बजाय, हर डिपेंडेंसी का अपना इंडिपेंडेंट StateMachine होता है. यह सभी डिपेंडेंसी को एक साथ प्रोसेस करता है.↩

  4. एक ही चरण में होने वाले कई tasks.lookUp कॉल को बैच बनाकर भेजा जाता है. एक साथ कई सबटास्क में होने वाले लुकअप की मदद से, एक साथ कई बैच बनाए जा सकते हैं.↩

  5. यह सैद्धांतिक तौर पर Java के स्ट्रक्चर्ड कॉनमुद्रा jeps/428 से मिलता-जुलता है.↩

  6. ऐसा करना, किसी धागे को पैदा करने और एक क्रम में कंपोज़िशन बनाने के लिए उसे जोड़ने जैसा है.↩