一個服務(service)通常指的是已知的介面或者抽象類，服務提供方就是對這個介面或者抽象類的實現，然後按spi標準存放到資源路徑META-INF/services目錄下，檔案的命名為該服務介面的全限定名。如有一個服務介面com.test.Service，其服務實現類為com.test.ChildService，那此時需要在META-INF/services中放置檔案com.test.Service，其中的內容就為該實現類的全限定名com.test.ChildService，有多個服務實現，每一行寫一個服務實現，#後面的內容為註釋，並且該檔案只能夠是以UTF-8編碼。
    這種實現方式，感覺和我們通常的開發方式差不多，都是定義一個介面，然後子類實現父類中定義的方法，為什麼要搞這麼一套標準以及單獨搞一個配置檔案？這種方式主要是針對不同的服務提供廠商，對不同場景的提供不同的解決方案制定的一套標準，舉個簡單的例子，如現在的JDK中有支援音樂播放，假設只支援mp3的播放，有些廠商想在這個基礎之上支援mp4的播放，有的想支援mp5，而這些廠商都是第三方廠商，如果沒有提供SPI這種實現標準，那就只有修改JAVA的原始碼了，那這個弊端也是顯而易見的，也就是不能夠隨著JDK的升級而升級現在的應用了，而有了SPI標準，SUN公司只需要提供一個播放介面，在實現播放的功能上通過ServiceLoad的方式載入服務，那麼第三方只需要實現這個播放介面，再按SPI標準進行打包成jar，再放到classpath下面就OK了，沒有一點程式碼的侵入性。

    以下是找到的幾篇文章：

    3、Developing a Service Provider using Java API(Service Provider Interface)：http://blog.csdn.net/fenglibing/article/details/7083526，這篇文章是轉的alexa發表在blogspot上面的，也是一個開發SPI的示例，有興趣的也可以看看；

    4、Add Mp3 capabilities to Java Sound with SPI：http://www.javaworld.com/javaworld/jw-11-2000/jw-1103-mp3.html，這是一個比較老的例子，基於jdk1.3的，因為在jdk1.3的時候還沒有支援mp3格式，只支援AU, AIF, MIDI, and WAV等格式，也是一個值得參考的示例。