fix 6856 DubboHandlerRegistry#removeService NPE issue.

[xiaoheng1]

What is the purpose of the change

fix DubboHandlerRegistry#removeService NPE issue.

see more detail from #6856.

Brief changelog

XXXXX

Verifying this change

XXXXX

Follow this checklist to help us incorporate your contribution quickly and easily:

• Make sure there is a GITHUB_issue field for the change (usually before you start working on it). Trivial changes like typos do not require a GITHUB issue. Your pull request should address just this issue, without pulling in other changes - one PR resolves one issue.
• Format the pull request title like [Dubbo-XXX] Fix UnknownException when host config not exist #XXX. Each commit in the pull request should have a meaningful subject line and body.
• Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
• Write necessary unit-test to verify your logic correction, more mock a little better when cross module dependency exist. If the new feature or significant change is committed, please remember to add sample in dubbo samples project.
• Run mvn clean install -DskipTests=false & mvn clean test-compile failsafe:integration-test to make sure unit-test and integration-test pass.
• If this contribution is large, please follow the Software Donation Guide.

[AlbumenJ]

LGTM.

[horizonzy]

The problem in DubboShutdownHook#destroyProtocols. It will destory all loaded protocols.
There will be GrpcProtocol and RegistryProtocol, the registryProtocol wrap GrpcProtol.
When GrpcProtol destory, the export will be destory, and the export will be removed from exportMap.
And in RegistryProtocol, it will unexport the grpcProtocol again, though the exportMap already clear, but the runnable which to remove handlerRegistry service still be execute.

[horizonzy]

dubbo/dubbo-config/dubbo-config-api/src/main/java/org/apache/dubbo/config/bootstrap/DubboBootstrap.java

Lines 1255 to 1282 in 34b744b

	public void destroy() {
	if (destroyLock.tryLock()) {
	try {
	DubboShutdownHook.destroyAll();
	if (started.compareAndSet(true, false)
	&& destroyed.compareAndSet(false, true)) {
	unregisterServiceInstance();
	unexportMetadataService();
	unexportServices();
	unreferServices();
	destroyRegistries();
	DubboShutdownHook.destroyProtocols();
	destroyServiceDiscoveries();
	destroyExecutorRepository();
	clear();
	shutdown();
	release();
	ExtensionLoader<DubboBootstrapStartStopListener> exts = getExtensionLoader(DubboBootstrapStartStopListener.class);
	exts.getSupportedExtensionInstances().forEach(ext -> ext.onStop(this));
	}
	} finally {
	destroyLock.unlock();
	}
	}
	}

And in dubboBootstrap#destory(), the line_1258 and line_1269 is repetitive, line_1269 can be remove.

[xiaoheng1]

If (exporterMap.remove(uri) != null && runnable != null) can also solve the problem. Now the removal logic of AbstractExporter is moved to the unexport method of the parent class. By using the unexport variable in the parent class to control whether Perform subsequent resource destruction, see https://github.com/apache/dubbo/pull/7286/files

[horizonzy]

If (exporterMap.remove(uri) != null && runnable != null) can also solve the problem. Now the removal logic of AbstractExporter is moved to the unexport method of the parent class. By using the unexport variable in the parent class to control whether Perform subsequent resource destruction, see https://github.com/apache/dubbo/pull/7286/files

I check it agian, that's fine.

[horizonzy]

LGTM.

[AlbumenJ]

LGTM.

[AlbumenJ]

@xiaoheng1 @horizonzy Thanks for contribution