- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
import java.io.PrintStream;
import java.util.concurrent.atomic.AtomicBoolean;
public final class ShredingerCat
extends AtomicBoolean
{
static final PrintStream o=System.out;
static final long initMsec=System.currentTimeMillis ();
public static final ShredingerCat INSTANCE = new ShredingerCat();
private ShredingerCat ()
{
set ( false );
o.println ( "Construct SingleBool" );
}
public final
void criticalSection(){
synchronized (this) {
pr ( "Enter critical section" );
ShredingerCat.sl ( 5 );
pr ( "Cat is " +(
get()
? "dead"
: "alive"
)
);
sl(100);
pr ( "Exit critical section" );
}
}
// ===================== HELPER STUFF ========================
static void pr(String s){
o.println ( s+(
System.currentTimeMillis ()- initMsec
));
}
static void sl(long l){
try {
Thread.sleep ( l );
}catch (InterruptedException e) {
}
}
}
Follow us!
Потратил полтора часа на этот иезуитский говно-пример. Если кому надо - дам подсказки.
Но уверяю вас - это знатнейшее говно.
implements Serializable
К сожалению, синглетон без readResolve - хреновый синглетон
Хотя вот когда я постил - вся надежда была только на тебя, честно.
Вот такой ответ сойдет?
Объект меняется в другом треде.
http://ideone.com/KYkqFp
Суть - сериализация использует еще один свой, неявный конструктор. И с помощью него можно создать сколько угодно таких объектов.
Получается, если класс заимплементил Serializable, то все его потомки до седьмого колена автоматом становятся сериализуемыми (если не перекроют readObject и readResolve и не выбросят оттуда исключение)?
P.S. Отвечу сам себе: All subtypes of a serializable class are themselves serializable.
private Object mutex=new Object();
..
synchronized (mutex) {
Добавление такого кода делает класс безопасным.
Хотя всё дело конечно не в synchronized, а в transient.
Угу, а sychronized(mutex) красиво спрятало бы истинную причину, по которой код становится безопасным (поломка сериализатора из-за не transient поля, класс которого не умеет в сериализацию)...
Но мне почему-то было не смешно.
Вспомнился случай - дали мне wsdl, который сам по себе превращает передаваемые данные в xml.
Подложил я значит заглушки - объекты.
И смотрю каждый объект с одним методом, и метод этот возвращает, возвращает значит сюрприз!
XML с обычной структурой поле - значение.
Вот такое говно .
2. Там не так уж много структур, чтобы поднимать protobuf, проще описать руками, протокол довольно простой, используется всего несколько типов данных
3. Структура протокола очень вариативна. Первые байты - номер команды. В зависимости от номера команды могут быть разные аргументы. Не уверен, насколько protobuf хорош при описании подобных структур (изменять которые крайне нежелательно).
По мне тут проще использовать фабрику команд с ручной маршализацией аргументов.
> Структура протокола очень вариативна.
Т.е. я так понимаю, что там несколько достаточно больших структур, у которых в зависимости от типа команды активны то одни то другие поля? Здесь бы, наверное, подошел флаг optional.
> другую сторону желательно не трогать
> протокол довольно простой
Тогда действительно не стоит заморачиваться с протобуферами, согласен.
*fix
fix