单纯使用
- (void)postNotification:(NSNotification *)notification;
- (void)addObserver:(id)observer selector:(SEL)aSelector name:(nullable NSNotificationName)aName object:(nullable id)anObject;
监听方法和发送方法在同一线程
监听方法执行顺序与监听加入顺序相同
发送方法会阻塞，等待监听方法执行完成
- (id <NSObject>)addObserverForName:(nullable NSNotificationName)name object:(nullable id)obj queue:(nullable NSOperationQueue *)queue usingBlock:(void (^)(NSNotification *note))block
当queue为空时，监听方法和发送方法在同一线程；不为空时，监听方法在指定的Queue上执行
监听方法执行顺序与监听加入顺序相同
发送方法会阻塞，等待监听方法执行完成
可以看出，postNotification:总是会卡住当前线程，待observer执行（如不特殊处理selector也会在postNotification:所在线程执行）结束之后才会继续往下执行。所以是同步的。
忘记remove的问题
这个就不进行测试了，因为我也没有iOS8以及之前的设备。直接写结论了:
若在iOS8或之前版本系统中，对一个对象addObserver:selector:name:object:（假设name为@“111”），但是并没有在dealloc的之前或之中，对其进行remove操作。那么，在发送通知（name为@“111”）的时候，会因为bad_access（野指针）而crash。
若在iOS9及以后，同上操作，不会crash。
iOS8及以前，NSNotificationCenter持有的是观察者的unsafe_unretained指针（可能是为了兼容老版本），这样，在观察者回收的时候未removeOberser，而后再进行post操作，则会向一段被回收的区域发送消息，所以出现野指针crash。而iOS9以后，unsafe_unretained改成了weak指针，即使dealloc的时候未removeOberser，再进行post操作，则会向nil发送消息，所以没有任何问题。
