<filename>en-us/docs/user/demos/delay-publish.json
{
  "filename": "delay-publish.md",
  "__html": "<h1>Delay publish service</h1>\n<p>If your services need time to warm up, such as: initialization cache or another reference resources has to be ready. You can use the delay feature to delay publishing services. We fine-tuned the service delay exposure logic in Dubbo 2.6.5, delaying the countdown of services that require delayed exposure until Spring initialization is complete. You won't be aware of this change while using Dubbo, so please be assured that use.</p>\n<h2>Prior to Dubbo-2.6.5</h2>\n<h3>Delay five second publish</h3>\n<pre><code class=\"language-xml\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">dubbo:service</span> <span class=\"hljs-attr\">delay</span>=<span class=\"hljs-string\">\"5000\"</span> /&gt;</span>\n</code></pre>\n<h3>Delay until Spring initialization is complete before exposing the service</h3>\n<pre><code class=\"language-xml\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">dubbo:service</span> <span class=\"hljs-attr\">delay</span>=<span class=\"hljs-string\">\"-1\"</span> /&gt;</span>\n</code></pre>\n<h2>Dubbo-2.6.5 and later</h2>\n<p>All services will be exposed after Spring initialization is complete, and you don't need to configure delay if you don't need to delay exposing the service.</p>\n<h3>Delay five second publish</h3>\n<pre><code class=\"language-xml\"><span class=\"hljs-tag\">&lt;<span class=\"hljs-name\">dubbo:service</span> <span class=\"hljs-attr\">delay</span>=<span class=\"hljs-string\">\"5000\"</span> /&gt;</span>\n</code></pre>\n<h2>The initialization deadlock problem of Spring 2.x</h2>\n<h3>Trigger condition</h3>\n<p>The service has already published when <code>Spring</code> parse the <code>&lt;dubbo:service /&gt;</code> element,but the <code>Spring</code> is still initializing other beans.If there is a request coming in, and the service implementation class has a call to <code>applicationContext.getBean ()</code> usage.</p>\n<ol>\n<li>\n<p>Request thread applicationContext.getBean() call, the first synchronization <code>singletonObjects</code> determine whether the existence of the bean, the synchronization does not exist to initialize the <code>beanDefinitionMap</code>, and re-synchronize <code>singletonObjects</code> write Bean instance cache.</p>\n<p><img src=\"../sources/images/lock-get-bean.jpg\" alt=\"deadlock\"></p>\n</li>\n<li>\n<p>But the <code>Spring</code> initialization thread,because need to determine the <code>Bean</code> is exist,Directly synchronize beanDefinitionMap to initialize, and synchronize singletonObjects write Bean instance cache.</p>\n<p><img src=\"../sources/images/lock-init-context.jpg\" alt=\"/user-guide/images/lock-init-context.jpg\"></p>\n</li>\n</ol>\n<p>This will cause the getBean thread to lock the singletonObjects first, then lock the beanDefinitionMap, and lock the singletonObjects again.The Spring initialization thread, the first lock beanDefinitionMap, then lock singletonObjects. Reverse lock thread deadlock, can not provide services, can not start.</p>\n<h3>Avoid ways</h3>\n<ol>\n<li>It is highly recommended not to call applicationContext.getBean() in the service implementation class, all using Spring's beans using IoC injection.</li>\n<li>If you really want to tune getBean(), you can put the configuration of Dubbo Spring final loading.</li>\n<li>If you do not want to rely on the configuration order, you can use <code>&lt;dubbo:provider delay =&quot;-1&quot;/&gt;</code> to make Dubbo expose the service after the Spring container has been initialized.</li>\n<li>If you use getBean() extensively, the equivalent of degenerating Spring to factory mode is to isolate Dubbo's service from a separate Spring container.</li>\n</ol>\n",
  "link": "/en-us/docs/user/demos/delay-publish.html",
  "meta": {}
}