ØMQ编程
看了些例子，你渴望开始在程序中使用ØMQ。开始前，先深呼吸，淡定，反思一下基本的建议将节省你的压力和困惑。
- 一步步学习ØMQ。它只是个简单的API不过它隐藏了无限的可能性。慢慢的一个个掌握这些可能性。
- 写优美代码。丑陋代码隐藏了问题并导致他人难以帮助你。你可能习惯于无意义的变量命名，但是人们阅读你的代码时可不会。名称使用真正的单词，表达出含义而不是“我疏忽了，没法告诉你这个变量到底干嘛用”。使用一致的缩进，干净的排版。写优美代码你的世界会更舒心。
- 制作的同时要测试你的作品。当你的程序无法工作时，你能知道是哪5行代码的问题。当你表演ØMQ魔法时尤其如此，你的头几次尝试就是无法工作。
- 当你发现事情不像预期的那样工作，拆分你的代码，分别测试，看看谁不能工作。ØMQ让你制作本质上模块化的代码，将它作为你的优势。
- 抽象（类，方法，什么的）吧，你需要他们。如果你复制粘贴一堆代码你也会复制粘贴到其中的错误。
取得上下文
ØMQ程序总是开始于创建一个上下文（context），然后使用它来创建套接字。在C语言中是调用zmq_ctx_new()。你应该在进程中仅仅创建和使用一个上下文。技术上，这个上下文是单个进程中所有套接字的容器，并作为进程内套接字的传输工具，这是连接进程内的线程的最快方法。如果一个进程有两个上下文，他们会像各自独立的ØMQ实例。如果那就是你想要的，OK，但其它情况下要记得：
在你的主线代码的开始调用zmq_ctx_new()，最后调用zmq_ctx_destroy()。
如果你使用系统函数fork()，每个进程需要自己的上下文。如果你在主进程的fork()之前调用了zmq_ctx_new()，那么子进程会得到他们自己的上下文。一般来说你会在子进程中做那些有趣的事情，那么就在父进程里管理这个。
干净退出
优雅的程序员与优雅的杀手共享一句格言：完事的时候要清理干净。如果你用类似Python语言版本的ØMQ，会自动的帮你释放。但是当使用C语言时，用完对象不得不小心释放，否则会内存泄漏，不稳定程序，会遭报应。
内存泄露是一方面，但是ØMQ对你如何退出程序是很挑剔的。原因是技术性的痛苦的，但后果是如果你没关闭套接字，zmq_ctx_destroy()函数会永远挂起。而且即使你关闭了所有的套接字，zmq_ctx_destroy()默认会永远等待挂起的连接或挂起的发送。除非你在关闭前将这些套接字的LINGER（徘徊）设置为0。
我们需要关心的ØMQ对象是消息、套接字、和上下文。幸运的是这很简单，至少在简单的程序中是这样的：
- 操作完毕的同时总是要使用zmq_msg_close()关闭消息。
- 如果你打开关闭很多的套接字，这可能是个信号，你需要重新设计程序。
- 退出程序时，关闭套接字然后调用zmq_ctx_destroy()。这会关闭上下文。
至少对于C开发来说是这样的。在带有自动对象销毁的语言中，当你离开作用域时套接字和上下文会被销毁。如果你使用异常处理，那么和其它资源一样，你得在“final”段中做清理。
如果你在做多线程工作，会比这复杂的多。下一章我们才到多线程的内容，但是因为你们有些人往往不顾警告，走不稳就开始试着跑，下面是一份快速而粗略的多线程ØMQ程序的干净退出指南。
首先，不要尝试在多个线程中使用同一个套接字。不，别解释你为何觉得这样特别有趣，请千万别这么做。下一步，你得将每个仍有请求的套接字都关闭。正确的方法是设置一个低的LINGER值（1秒），然后关闭套接字。如果你的语言绑定没有在你销毁上下文时自动帮你这么处理，我建议你可以发一个补丁。
最后，销毁上下文。这将导致关联线程（也就是共享上下文）中的所有阻塞的接收、轮询、发送都返回一个错误。捕获那个错误，然后设置徘徊，关闭此线程的套接字，然后退出。不要对相同的上下文销毁两次。主线程的zmq_ctx_destroy将阻塞直到它知道的所有套接字都已安全关闭。
可不是！这够复杂够痛苦了，任何称职的语言绑定的作者都应该将这些步骤自动化，好让这个套接字关闭的舞蹈不再是必要的。